At work we've been putting together a coding standards document so that everyone adheres to similar code usage. This keeps everyone on the same page and makes it easy for another programmer to modify code that he/she did not write. Whenever we arrive at a controversial coding standard we have an email discussion about the pros and cons of the defined standard. One that came up recently was when to use the
var keyword. During the discussion I realized that half of the people involved did not actually understand what the
var keyword does and what it's used for. I decided to clear the air a little bit and do a quick write-up to explain it.
The most common misunderstanding that I encounter in regards to the
var keyword is that it's not strongly-typed. Which, if it were true, would be a horrible thing to do in a strongly-typed language like C#. This is not the case. Variables declared with
var use a concept called type inference to strongly-type the variable. There is essentially no difference between explicitly declaring the variable type and using the
var keyword. For example:
var errorLogWriter = new ErrorLogWriter();
is exactly the same as
ErrorLogWriter errorLogWriter = new ErrorLogWriter();
The only difference between these two statments is that the second one takes longer to type because you have to write out the type name twice. When you use
var the compiler will use type inference to look at the right-hand side of the statement and infer the type. The variable declared with
var would still have full intellisense and would be of type
ErrorLogWriter. Despite the popular misconception about this keyword, the compiler still catches typing errors at runtime just like a strongly-typed language would.
var errorLogWriter = new ErrorLogWriter(); errorLogWriter = new DateTime();
The above statement would cause a compiler error saying that it cannot implicitly convert type
DateTime to type
ErrorLogWriter. This is because the variable
errorLogWriter was typed as
ErrorLogWriter just as if you had specified the type the old fashioned way.
When to Use it
var keyword was created for use with anonymous types where you cannot know the type of the object. This is especially useful with LINQ when you want to return a set of objects with only select properties on them. Some have presented the argument to me that using the
var keyword with anything other than anonymous types is wrong because that's not what they were created for. To me that's like saying using the internet to do your banking and chat with friends is wrong because it was originally created for the military to store and protect information. That said, there are a few places where I agree that using
var becomes unreadable. For example:
var errorLogWriter = LogWriterFactory.CreateErrorLogWriter();
The above statement is getting a little obfuscated and hard to read. Because of this, I would suggest only using type inference where the type is easily seen just to the right of the equals sign. I also suggest naming your variable the same as the type (except with the first letter lowercase) where possible. This allows the developer to see the variable and immediately know what it is without hunting for the instantiation statement.
Another great time to use
var is with generics.
var myGenericType = new Dictionary<string, Dictionary<string, IEnumerable<string>>>();
looks better than this:
Dictionary<string, Dictionary<string, IEnumerable<string>>> myGenericType = new Dictionary<string, Dictionary<string, IEnumerable<string>>>();
Obviously nesting that many generics is horrible looking and should be avoided if possible, but in the rare event that you have a messy type declaration like that
var is useful. In a messy type declaration It's not immediately obvious what the type is no matter how you write it, so why not save yourself the hassle and use
var for the first part. Overuse of
var can be annoying, but I feel like it definitely has it's place.
Following these guidelines will make programming easier, quicker, and more efficient in the long run. I'm always for anything that reduces the amount of code I have to write and is still readable. I hope this clears up some misconceptions about the