There are a lot of discussion around it. I would like to use var everywhere because I have strong arguments that it makes code more readable. But before sharing my experience and conclusion let’s take a look some notes:
“Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types.” C# Reference, MSDN
Vladimir Kelman said
“C# documentation generally uses var only when it is required”This is a bit obsolete approach intended for people who are completely new and unaware of ideas of functional programming, type inference, etc. After reading some books on F#, Scala, etc. (one of my favorites ishttp://www.functional-programming.net/) it becomes clear when to use and when not to use var. With constructors and type casting operators it doesn’t make sense to use explicit types – just makes code less readable. Var also makes sense to use in all cases when type is clear from a context, when type is automatically generated and/or very complicated.
Good starting point was given by Ilya’s: Using var keyword can significantly improve your code, not just save you some typing. However, it may require discipline to apply good practices when using implicitly typed variables. Here is my list:
- It removes code noise.
There are a lot of cases, when implicitly typed local will reduce amount of text developer needs to read, or rather skip. Declaring local variable from new object expression or cast expression requires specifying type twice, if we don’t use “var”. With generics it can lead to a lot of otherwise redundant code. Another example would be iteration variable in foreach over Dictionary<TKey,TValue>.
- It is required to express variables of anonymous type
. This is pretty obvious – you cannot declare local variable of anonymous type without using var.
- It induces better naming for local variables
. When you read local variable declaration with explicit type, you have more information at that moment and something like “IUnitTestElement current” makes sense. However, when this local variable is used later, you read “current” which takes some time to figure out the meaning. Using “var currentElement” makes it easier to read at any place.
- It induces better API.
When you let compiler deduce type from method return type or property type, you have to have good types in the first place. When you don’t have explicit type in the initialization expression, you have to have best names for members.
- It induces variable initialization.
It is generally a good practice to initialize variable in the declaration, and compiler needs initializer to infer type for local variable declared with “var” keyword.
- It doesn’t require using directive
. With var, you don’t have explicit reference to type, as compiler infers type for you, so you don’t need to import namespace when you need a temporary variable.
To summarize the list above, by actively using
var keyword and refactoring your code as needed you improve the way your code speaks for itself.
Pretty nice thoughts, but I have another experience and another arguments.
I believe evertime I tried to specify type I have a smell in my code. Extra argument from me: we are talking about “easy to read”. Why do we discuss it only for declaration line?
var cat = shop.GetAnimal();
Do I care in this line about type? NO. Because I have absolutely a beauty variable name. But it’s not good example! Good example is to show that we don’t care about type at all and focus on our habit to see type on left side… Let’s see how we using this variable:
var cat = shop.GetAnimal();
…
cat.Meow();
Do I really believe that during reading cat.Meow() I care about type? Why do I need type during the reading? ”Readiness” is defined not by initialization of the variable, it’s defined by using variable. If you eager about using concrete type you MUST write like this:
Cat cat = shop.GetAnimal(); (1)
…
(Cat)cat.Meow(); (2)
(2) Be honest! If you need a type for understanding use it everywhere. Here (2) is a type as you like
) Please be honest, it’s not logical to use type in (1) and avoid in (2). My conclusion, we want to see code without var due to our habits, rather than to make code readable.
And the last bullet point. Try to ask your-self are you business developer or technical programmer? For me it’s important to read business logic of the function and focus on business domain/behaviour rather than get stuck with technical implementation forced by concrete programm language.
As for me implementation of
internal DSL using concrete language should follow such rules
- simplify as much as possible (var is an example of simplification communication interface for a reader)
- close to domain – avoid thinking about technical details and focus on business domain and behaviour; and object communication, rather than types and interfaces
Another point is. Let’s think about argument for avoiding using var. “I want to know type”. Please pronounce several types and think about it. Doesn’t it remaind well-known reincarnation Hungarian notation? Of coursee we don’t hide type inside variable, but we hide type inside declaration. Why as a reader do I need type in declaration? What are the problems to understand further code? Why should I as a reader care about type in this line of code: cat.Meow()? It means I need type only in one place in declaration. And I don’t use type and knowledge about object type further. Let’s get read of dead code.
My conclusion. Using concrete type is anti-pattern as comments, long methond, god class, high coupling and etc. And if you don’t understand nature of the object and want to comment it by using type you must apply refactorings.
If you disagree, please don’t explain why and make assumption that I know a lot of traditional arguments about the topic. I don’t like discuss theoretical assumptions and personal habits. Give me your real case where we could not avoid using concrete type. But be aware I will challange your code with refactorings technics before a deep discussion
I prefer to learn by real examples and real cases.