It seems that more and more C# code I read uses the var type identifier:
foreach (var itemChange in ItemChanges)
{
//...
}
var is a C# 3.x+ feature, isn't it? without using that, your code is more compatible with other versions too.
And there is lots of interesting questions in SO, when you search "var C#"
var is a C# 3.0 feature only mandatory in anonymous type
Because following code
var v = new { Amount = 108, Message = "Hello" };
dynamically create a new anonymous type, var usage is mandatory. For example, var is particularly useful in Linq where type are often created dynamically.
In any other situations, it's only a matter of taste for final application (it's resolved during compilation). But for code readers, I think 'var' is less informative that type itself.
There is no technical reason. If the type cannot be inferred at compile time then the code will not compile.
You are right in stating there are instances where it may be better to use an explicit type for readabilty, e.g.
var obj = SomeMethod(); // what's the type? you'd have to inspect SomeMethod()
SomeClass obj = SomeMethod(); // the type is obvious
but other instances where using var makes perfect sense, e.g.
var obj = new SomeClass(); // the type is obvious
SomeClass obj = new SomeClass(); // the duplication of type is unnecessary
There is no technical reason to use var, other than anonymous types, in any given state of the program.
However, using var allows the program to change without you needing to edit it. Given
public int SomeMethod(){}
public List<T> SomeOtherMethod<T>(T parameter);
then
var x = SomeMethod();
var y = SomeOtherMethod(x);
Will work (and y will be List<int>
). If you had used
int x = SomeMethod();
List<int> y = SomeOtherMethod(x);
then if SomeMethod()
were changed to return long
, then you'd have to change the definition of y.
I've seen this kind of thing propagate throughout a program, requiring hundreds of changes. The particular case was changing data access code to return ReadOnlyCollection<T>
rather than List<T>
. There were so many code changes required, that I changed all explicit mentions of List<T>
to var, and the code will never need to change again.
The only technical reason I know of is that you can perform implicit casts without var
, e.g.
int i = 5;
double a = i; // implicit cast with explicit types
but here I much prefer var
as it makes the cast explicit; while I don't care so much about the types I do care when I'm performing a representation changing type conversion:
var a = (double)i; // explicit cast with implicit types
But really the general reason is readability, as you said. The question you need to ask yourself is why you think the exact concrete type is important for readability? Do you always write Linq queries calling out the concrete type, e.g.
from ItemChange itemChange in ItemChanges
// instead of
from itemChange in ItemChanges
Similarly, do you always call out the type arguments to generic methods instead of using type inference, e.g.
ItemChanges.Select<ItemChange, ItemChange>((ItemChange itemChange) => ...);
// instead of
ItemChanges.Select(itemChange => ...);
Or are you happy to let the compiler do some work for you and let it work out the types, at the 'expense' of not having the type information explicitly stated?
If you're happy with type inference in linq and generic methods, then you've already made the decision that you're OK with not having types explicitly spelled out everywhere, and you probably haven't found your code to be any less readable as a result (in fact, you've probably found quite the opposite). So using var
is just another step down the same path that you're already on.
No, just readability.