question on anonymous type
timor...@gmail.com
I have a question on anonymous type
I can write :
using (StreamWriter writer = new StreamWriter(...))
and I can write this too :
using (var writer = new StreamWriter(...))
What is the best ? Which option should I choose ?
The first seems to be more readable ...
Thanks in advance for your answer
Martin Bonner
> Hi all,
>
> I have a question on anonymous type
>
> I can write :
> using (StreamWriter writer = new StreamWriter(...))
>
> and I can write this too :
> using (var writer = new StreamWriter(...))
>
> What is the best?
> Which option should I choose ?
> The first seems to be more readable ...
Then use that. Personally, I don't like the duplication involved in
writing "StreamWriter" twice (and it gets worse when I want to say
Dictionary<string,List<Entry>> or some other equally complicated
generic) ... but it's up to you.
Note that var becomes more important when you start using LINQ
expressions (where the actual types can be rather difficult to write
down).
Peter Morris
> using (StreamWriter writer = new StreamWriter(...))
>
> and I can write this too :
> using (var writer = new StreamWriter(...))
>
> What is the best ? Which option should I choose ?
In this case I see no benefits in either, except "var" is quicker to type.
![Jon Skeet [C# MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUE-UkOE6oV07-Al6msToqDuW9IN9k9G_wNeBLWDr7OkQdq7K1C5zHX3w=s40-c)
Jon Skeet [C# MVP]
Actually, you have a question on implicitly typed local variables.
Anonymous types are the types created when you write code like this:
new { Name="Jon" }
The two features are often used together, but don't have to be.
> I can write :
> using (StreamWriter writer = new StreamWriter(...))
>
> and I can write this too :
> using (var writer = new StreamWriter(...))
>
> What is the best ? Which option should I choose ?
> The first seems to be more readable ...
Well, the first contains redundant information - but it's more
expicit. It's largely a matter of taste though. I've found myself
using implicitly typed local variables quite a bit with no loss of
readability.
Jon
timor...@gmail.com
That's mean that in IL language, both instructions are equivalent ?
Jon Skeet [C# MVP]
> Thanks all for your answer.
>
> That's mean that in IL language, both instructions are equivalent ?
Yes. Don't forget that C# 3 still compiles to IL run by the 2.0 (or
2.0SP1) CLR. The new features of C# 3 don't require runtime support.
Anonymous types are just compiled into normal types with names which
are valid in IL but invalid in C#. Implicitly typed local variables
just have their types inferred by the compiler and used as normal.
Jon
timor...@gmail.com
Best regards
Ignacio Machin ( .NET/ C# MVP )
Hi,
I would go for the first one, in this case using an anonymous type is
unnecesary, somewhere I read a post that lamented that MS allowed such
a construction.
BTW, the above is not an anonymous type expression
Marc Gravell
> unnecesary, somewhere I read a post that lamented that MS allowed such
> a construction.
Somewhere there is a line, and I don't claim to know where /exactly/
it is - but sometimes even in this scenario, "var" genuinely improves
the code. For example, what if it was a
KeyContainerPermissionAccessEntryCollection*, or maybe a
Dictionary<SomeLudicrouslyLongTypeName, AnotherLongTypeName>...
repeating all that lot in the same expression (which is a pre-
requisite for "var) is just fluff.
*=yes, this isn't IDisposable, but that isn't the point I'm trying to
make...
Marc
Arne Vajhøj
> I have a question on anonymous type
>
> I can write :
> using (StreamWriter writer = new StreamWriter(...))
>
> and I can write this too :
> using (var writer = new StreamWriter(...))
>
> What is the best ? Which option should I choose ?
> The first seems to be more readable ...
I would go for the first as being more readable. Most
C# programmer will be used to reading the type first.
And you will not be typing the class name twice. The
IDE should propose it the second time.
Arne
Jon Skeet [C# MVP]
> > What is the best ? Which option should I choose ?
> > The first seems to be more readable ...
>
> I would go for the first as being more readable. Most
> C# programmer will be used to reading the type first.
At the moment, yes. I think things will change as C# 3 becomes more
widely known.
> And you will not be typing the class name twice. The
> IDE should propose it the second time.
True, but it's not really about typing. It's about information
redundancy.
Ironically, the thing which the OP *didn't* do which I often would is
use a base type or interface:
using (TextWriter writer = new StreamWriter(...))
that adds information - it tells the reader that actually, any
TextWriter will do for what we need to call - it just so happens that
it uses StreamWriter at the moment. At the point you're adding this
extra information, there is no longer redundancy for implicit typing
to remove.
Jon
Arne Vajhøj
> On Jun 5, 3:34 am, Arne Vajhøj <a...@vajhoej.dk> wrote:
>>> What is the best ? Which option should I choose ?
>>> The first seems to be more readable ...
>> I would go for the first as being more readable. Most
>> C# programmer will be used to reading the type first.
>
> At the moment, yes. I think things will change as C# 3 becomes more
> widely known.
I doubt it.
C# 3 will become widely known.
But most C# developers will have learned C# in earlier versions
and many of them will also use other languages from let us call
it "the C syntax family".
>> And you will not be typing the class name twice. The
>> IDE should propose it the second time.
>
> True, but it's not really about typing. It's about information
> redundancy.
I can not see that redundancy as a big problem. The compiler
will catch it if inconsistent changes are made.
Arne
Jon Skeet [C# MVP]
> > At the moment, yes. I think things will change as C# 3 becomes more
> > widely known.
>
> I doubt it.
>
> C# 3 will become widely known.
>
> But most C# developers will have learned C# in earlier versions
> and many of them will also use other languages from let us call
> it "the C syntax family".
Yes, I use Java day to day professionally now - and regularly miss
"var".
If people ignore the C#-specific features of C# 3 just because they're
not used to them, they'll be really missing out.
> >> And you will not be typing the class name twice. The
> >> IDE should propose it the second time.
> >
> > True, but it's not really about typing. It's about information
> > redundancy.
>
> I can not see that redundancy as a big problem. The compiler
> will catch it if inconsistent changes are made.
The problem with redundancy isn't the possibility for inconsistency -
it's the lack of information density. It takes more space redundantly
specifying information, so there's more to wade through when reading
the code.
--
Jon Skeet - <sk...@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
Arne Vajhøj
>>> At the moment, yes. I think things will change as C# 3 becomes more
>>> widely known.
>> I doubt it.
>>
>> C# 3 will become widely known.
>>
>> But most C# developers will have learned C# in earlier versions
>> and many of them will also use other languages from let us call
>> it "the C syntax family".
>
> Yes, I use Java day to day professionally now - and regularly miss
> "var".
>
> If people ignore the C#-specific features of C# 3 just because they're
> not used to them, they'll be really missing out.
If the only think they miss out is stuff like this that has no
functional impact, then they will survive.
>>>> And you will not be typing the class name twice. The
>>>> IDE should propose it the second time.
>>> True, but it's not really about typing. It's about information
>>> redundancy.
>> I can not see that redundancy as a big problem. The compiler
>> will catch it if inconsistent changes are made.
>
> The problem with redundancy isn't the possibility for inconsistency -
> it's the lack of information density. It takes more space redundantly
> specifying information, so there's more to wade through when reading
> the code.
The possibility of inconsistency is the classic reason to avoid
redundancy.
Disk space is cheap.
And I find it hard to believe that the usage of var instead of
explicit classname should take longer time to read.
Arne
Tim Jarvis
> > At the moment, yes. I think things will change as C# 3 becomes more
> > widely known.
>
> I doubt it.
>
> C# 3 will become widely known.
>
> But most C# developers will have learned C# in earlier versions
> and many of them will also use other languages from let us call
> it "the C syntax family".
I think though that var is a special case because in some circumstances
its the only effective way to reference a type, anonymous types gained
from projection out of a linq query for example.
var report = from line in SomeEnumeration
select new
{
Value = line.SomeValue,
AnotherValue = line.AnotherValue
}
foreach (var reportline in report)
{
//...
}
I this will become common enough for var to be considered "normal" C#
syntax.
Cheers Tim.
--
Jon Skeet [C# MVP]
> > If people ignore the C#-specific features of C# 3 just because they're
> > not used to them, they'll be really missing out.
>
> If the only think they miss out is stuff like this that has no
> functional impact, then they will survive.
I'm sure they'll survive - they just may not be as productive.
> > The problem with redundancy isn't the possibility for inconsistency -
> > it's the lack of information density. It takes more space redundantly
> > specifying information, so there's more to wade through when reading
> > the code.
>
> The possibility of inconsistency is the classic reason to avoid
> redundancy.
In many other scenarios, yes. Not here.
> Disk space is cheap.
Who was arguing that disk space was relevant?
> And I find it hard to believe that the usage of var instead of
> explicit classname should take longer time to read.
It changes the emphasis of the code. Eric Lippert puts it well:
http://csharpindepth.com/ViewNote.aspx?NoteID=61
Arne Vajhøj
> Arne Vajhøj wrote:
>>> At the moment, yes. I think things will change as C# 3 becomes more
>>> widely known.
>> I doubt it.
>>
>> C# 3 will become widely known.
>>
>> But most C# developers will have learned C# in earlier versions
>> and many of them will also use other languages from let us call
>> it "the C syntax family".
>
> I think though that var is a special case because in some circumstances
> its the only effective way to reference a type, anonymous types gained
> from projection out of a linq query for example.
>
> var report = from line in SomeEnumeration
> select new
> {
> Value = line.SomeValue,
> AnotherValue = line.AnotherValue
> }
>
> foreach (var reportline in report)
> {
> //...
> }
Sure - there are cases where var is necessary. I do not disagree
with that.
The question discussed is whether it should replace declarations
of well known types.
Arne
Arne Vajhøj
>>> If people ignore the C#-specific features of C# 3 just because they're
>>> not used to them, they'll be really missing out.
>> If the only think they miss out is stuff like this that has no
>> functional impact, then they will survive.
>
> I'm sure they'll survive - they just may not be as productive.
I doubt it.
It has been discussed as a new feature for Java and it is nowhere
near the top of the popularity list.
>>> The problem with redundancy isn't the possibility for inconsistency -
>>> it's the lack of information density. It takes more space redundantly
>>> specifying information, so there's more to wade through when reading
>>> the code.
>> The possibility of inconsistency is the classic reason to avoid
>> redundancy.
>
> In many other scenarios, yes. Not here.
>
>> Disk space is cheap.
>
> Who was arguing that disk space was relevant?
You said that it takes more space.
>> And I find it hard to believe that the usage of var instead of
>> explicit classname should take longer time to read.
>
> It changes the emphasis of the code. Eric Lippert puts it well:
> http://csharpindepth.com/ViewNote.aspx?NoteID=61
I think it is the other way around.
X o = new X();
emphasizes the what and not the how.
First you read that you have an o of type X.
Then you may or may not read where you got it from.
var o = new X();
First you read that you have an o without more info and
then you has to read where it came from to figure out what
it is.
Arne
Jon Skeet [C# MVP]
> > I'm sure they'll survive - they just may not be as productive.
>
> I doubt it.
>
> It has been discussed as a new feature for Java and it is nowhere
> near the top of the popularity list.
That doesn't mean it won't prove to be useful in C#. People often
underestimate how useful a feature will be when they haven't had it.
Look up Blub's Paradox.
> >>> The problem with redundancy isn't the possibility for inconsistency -
> >>> it's the lack of information density. It takes more space redundantly
> >>> specifying information, so there's more to wade through when reading
> >>> the code.
> >> The possibility of inconsistency is the classic reason to avoid
> >> redundancy.
> >
> > In many other scenarios, yes. Not here.
> >
> >> Disk space is cheap.
> >
> > Who was arguing that disk space was relevant?
>
> You said that it takes more space.
I was talking about *visual* space. *That* is important - disk space
(for source code) generally isn't.
> >> And I find it hard to believe that the usage of var instead of
> >> explicit classname should take longer time to read.
> >
> > It changes the emphasis of the code. Eric Lippert puts it well:
> > http://csharpindepth.com/ViewNote.aspx?NoteID=61
>
> I think it is the other way around.
>
> X o = new X();
>
> emphasizes the what and not the how.
>
> First you read that you have an o of type X.
>
> Then you may or may not read where you got it from.
>
> var o = new X();
>
> First you read that you have an o without more info and
> then you has to read where it came from to figure out what
> it is.
No, you're missing the point - with var, you tend to concentrate on
what you *do* with o rather than the exact type of o (which is part of
the "how").
Arne Vajhøj
>>> I'm sure they'll survive - they just may not be as productive.
>> I doubt it.
>>
>> It has been discussed as a new feature for Java and it is nowhere
>> near the top of the popularity list.
>
> That doesn't mean it won't prove to be useful in C#. People often
> underestimate how useful a feature will be when they haven't had it.
> Look up Blub's Paradox.
I don't think that apply very well. A rather big percentage of Java
programmers also program in C#.
>>>> And I find it hard to believe that the usage of var instead of
>>>> explicit classname should take longer time to read.
>>> It changes the emphasis of the code. Eric Lippert puts it well:
>>> http://csharpindepth.com/ViewNote.aspx?NoteID=61
>> I think it is the other way around.
>>
>> X o = new X();
>>
>> emphasizes the what and not the how.
>>
>> First you read that you have an o of type X.
>>
>> Then you may or may not read where you got it from.
>>
>> var o = new X();
>>
>> First you read that you have an o without more info and
>> then you has to read where it came from to figure out what
>> it is.
>
> No, you're missing the point - with var, you tend to concentrate on
> what you *do* with o rather than the exact type of o (which is part of
> the "how").
But what I do with o.m() actually depends on what o is !
Arne
Jon Skeet [C# MVP]
> > That doesn't mean it won't prove to be useful in C#. People often
> > underestimate how useful a feature will be when they haven't had it.
> > Look up Blub's Paradox.
>
> I don't think that apply very well. A rather big percentage of Java
> programmers also program in C#.
In which case it would be interesting to see whether it becomes more
requested in a few years' time, when those developers have been using
C# 3 and become used to "var". It's too early to take results *now* and
draw any conclusions.
> > No, you're missing the point - with var, you tend to concentrate on
> > what you *do* with o rather than the exact type of o (which is part of
> > the "how").
>
> But what I do with o.m() actually depends on what o is !
But if it's obvious when *reading* the code what's going on, the
details only matter when you're looking more deeply into the code. When
I'm working on a problem, I don't actually need to read most of the
code closely - I'll skim a lot of it. Implicitly typed local variables
help the skimming mode, and arguably slightly harm the detailed part.
(Usually it's still pretty obvious what the type actually is, IMO.)
The aid to the skimming mode is significant though.
Arne Vajhøj
>>> That doesn't mean it won't prove to be useful in C#. People often
>>> underestimate how useful a feature will be when they haven't had it.
>>> Look up Blub's Paradox.
>> I don't think that apply very well. A rather big percentage of Java
>> programmers also program in C#.
>
> In which case it would be interesting to see whether it becomes more
> requested in a few years' time, when those developers have been using
> C# 3 and become used to "var". It's too early to take results *now* and
> draw any conclusions.
True. It could change.
But I doubt it will happen. It is not exactly a new concept.
I don't even think C# would have gotten it if it had not been for LINQ.
>>> No, you're missing the point - with var, you tend to concentrate on
>>> what you *do* with o rather than the exact type of o (which is part of
>>> the "how").
>> But what I do with o.m() actually depends on what o is !
>
> But if it's obvious when *reading* the code what's going on, the
> details only matter when you're looking more deeply into the code.
I don't consider the type a detail in OOP.
> When
> I'm working on a problem, I don't actually need to read most of the
> code closely - I'll skim a lot of it. Implicitly typed local variables
> help the skimming mode, and arguably slightly harm the detailed part.
I believe many people will want to know the type even for skimming.
Arne
Jon Skeet [C# MVP]
> > In which case it would be interesting to see whether it becomes more
> > requested in a few years' time, when those developers have been using
> > C# 3 and become used to "var". It's too early to take results *now* and
> > draw any conclusions.
>
> True. It could change.
>
> But I doubt it will happen. It is not exactly a new concept.
It's not a new *concept* but it may be new in *practice* to a lot of
people. Heck, I'd never used a lambda expression in anger until C# 3,
and those have been around for ages too.
> I don't even think C# would have gotten it if it had not been for LINQ.
Quite possibly not - but that doesn't mean the feature isn't handy
outside LINQ. Extension methods could be thought of in the same way,
and those *are* on the cards for Java 7.
> > But if it's obvious when *reading* the code what's going on, the
> > details only matter when you're looking more deeply into the code.
>
> I don't consider the type a detail in OOP.
I do when it's a matter of skimming code. Do I care whether I'm using
an array or a List<T> if I'm just indexing it? Not really. Do I care
whether something is definitely a LinkedList<T> or any old
IEnumerable<T> if all I'm doing is iterating over it? Not really.
Bear in mind that the declared variable type won't tell you what the
actual type is anyway (unless it's a sealed type) - if you need that
information you've *got* to look to the right hand side of the
assignment. If you're going to do that, how much do you care about the
LHS?
I'm not saying it isn't important information - just that I don't find
it important in certain modes of reading code, and those modes account
for quite a lot of the time I may spend reading code (either for
debugging and trying to get to the critical spot quickly, then
understanding that critical spot in detail, or just getting the flavour
of a class).
But hey, it's definitely a style thing. If you don't like it, that's
fine.
> > I'm working on a problem, I don't actually need to read most of the
> > code closely - I'll skim a lot of it. Implicitly typed local variables
> > help the skimming mode, and arguably slightly harm the detailed part.
>
> I believe many people will want to know the type even for skimming.
Then I believe they won't skim as quickly as they can, for the basic
level of "what's this method trying to achieve?" that I aim for with
skimming.