views:

994

answers:

6

I'm currently using ReSharper's 30-day trial, and so far I've been impressed with the suggestions it makes. One suggestion puzzles me, however.

When I explicitly define a variable, such as:

List<String> lstString = new List<String>();

ReSharped adds a little squiggly green line and tells me to:

Use implicitly type local variable declaration.

If I then follow its suggestion, ReSharper changes the line of code to:

var lstString = new List<String>();

So, is there some sort of performance gain to be had from changing the List<String> to a var, or is this merely a peculiarity of ReSharper? I've always been taught that explicitly defining a variable, rather than using a dynamic, is more optimal.

+9  A: 

Nope. They emit the exact same IL.

It's just a matter of style.

var has the benefit that makes it easier for you to change the return type of functions without altering other parts of source code. For example change the return type from IEnumerable<T> to List<T>. However, it might make it easier to introduce bugs.

Mehrdad Afshari
Actually, this is a poor use of var. It should only be used when the type is self-evident from the context. If you can change the return type of a method without changing its name then you shouldn't be using var because the type involved is not obvious.
Stephen Martin
@Stephen: Why is it bad when the type of an expression is not immediately obvious?
Andreas Huber
The use of var as an ambiguous symbol severely reduces readability and understandability. The quick grasp of the type of an object when reading code leads to far quicker and higher comprehension.
Stephen Martin
I agree with Stephen. I'm not a fan of unnecessary var, when you can just write double, int, float, string, Page. I only use var on very long type names and anonymous types. var usually decreases readability
Mehrdad Afshari
Andreas Huber
The name should describe what the object is not what type it is (Hungarian anyone?), of course there is some overlap between the two but why remove information for no reason. DRY is a nice aphorism and should always be kept in mind but don't elevate it to a rule for all occasions.
Stephen Martin
@Stephen: Why repeat information for no reason? Don't bother, I'm obviously not going to convince you. My point was that the use of var in the absence of anonymous types is a matter of taste.
Andreas Huber
+1  A: 

var is different than dynamic keyword, also compiler will convert var keywords to actual type handle

erdogany
+5  A: 

The var keyword does not actually declare a variable with a dynamic type. The variable is still statically typed, it just infers the type from the context.

Its a nice shortcut when you have a long typename (generic typenames can be long)

Matt Brunell
The main thing being you can't assign an int to a var one moment and a string the next, like you can with real dynamic types. Once the type is set, it's stuck that way. You still get full intellisense support and everything.
Joel Coehoorn
+27  A: 

So, is there some sort of performance gain to be had from changing the List to a var

No but this is not the only valid reason for a refactoring. More importantly, it removes redundance and makes the code shorter without any loss in clarity.

I've always been taught that explicitly defining a variable, rather than using a dynamic, is more optimal.

You misunderstand what var means. This is not in any way dynamic, since it produces the same output. It just means that the compiler figures the type for the variable out by itself. It's obviously capable of doing so, since this is the same mechanism used to test for type safety and correctness.

It also removes a completely useless code duplication. For simple types, this might not be much. But consider:

SomeNamespace.AndSomeVeryLongTypeName foo = new SomeNamespace.AndSomeVeryLongTypeName();

Clearly, in this case doubling the name is not just unnecessary but actually harmful.

Konrad Rudolph
Thank you for the clarification on 'var' not being the same as dynamic, I didn't not realize that.
JustinT
+1 nice explanation.
JonH
A: 

Less typing = more productivity :)

Martin Clarke
Actually: Less readability = less productivity
Christoph Rüegg
Good, then var is better all around. var is often more readable, simply because there's much less reading to do.
Joel Coehoorn
The only times that var is more readable is in the case of creating objects with extremely long (often generic) type names as suggested by Konrad. There the var can be matched to the type almost instantly and the removal of the large number of extra characters improves understandability.
Stephen Martin
In most other cases, and especially in the case of using a var to declare a variable that is initialized by a return value, the loss of understandability due to the introduction of ambiguous symbols decreases readability considerably.
Stephen Martin