Using "var" to simplify code and avoid redundancy
You’ve probably already heard of the new "var" keyword that you can use to declare variables in your .NET code. I wanted to clear up some quick myths and give a quick overview of when it’s most valuable.
If you haven’t heard of it, you can now use this syntax:
var c = new Cat();
Instead of this:
Cat c = new Cat();
As Jeff Atwood mentioned, it’s a great way to avoid redundancy. It’s obvious that you’re creating a "Cat" object, why do you have to say it twice?
The most important thing to realize, is that it’s NOT a var like in JavaScript or other languages (DIM in VB). It really is 100% a "Cat" object, complete with intellisense. The generated IL would be no different than specifying the type when you declare it. It’s simply a compiler trick.
Another important thing to remember is that you the assignment must be combined with the declaration. If that wasn’t the case, readability would be very poor.
var myName = "Jason"; //Allowed var yourName; //Not allowed yourName = "Bob"; //Glad you can't do this
What are some really good examples of when it ideally should be used:
List<Dictionary<int, string>> customers = new List<Dictionary<int, string>>(); //Yuck!
var customers = new List<Dictionary<int, string>>(); //Yay!
OrderRepository orderRepo = (OrderRepository)ctx.GetObject("orderRepository"); //Yuck!
var orderRepo = (OrderRepository)ctx.GetObject("orderRepository"); //Yay!
string name = "Jason Young"; //Kinda yucky
var name = "Jason Young"; //Kinda better
As you can see, those examples have obvious redundancy. Using the "var" keyword increases readability, and makes it easier to change if needed.
There are certainly times when its use is questionable. In the following example, I’m calling a function that returns some data. Since I’m not explicitly defining the type that is being returned from that function, I have to do some digging to figure out the type being returned. In this case, you’ll have to define the correct way to handle it in your coding standards.
var data = GetData();
Another potential readability issue comes up in the following case. You might not want to use the "Circle" specific methods (Circle inherits from Shape).
Shape s = GetCircle(); //I see what you're doing var s = GetCircle(); //Do you want a shape, or a circle?
Aside from a couple of decisions that need to be made in your organization, I think this is a great addition, and should make our lives as developers a little bit easier. It’s just another tool for our toolbelt. With great power comes great responsibility

Obishawn said,
Wrote on June 25, 2008 @ 3:34 pm
In regards to your last example, I just ran into that today where I had IShape shape = GetShape() where returned an object of type Shape. The nice thing is, Resharper did not complain telling me I should have switched that to var. It must have realized that I wanted to impose that kind of restriction on that object or something. Funny thing is, I didn’t mean to use the interface for that since GetShape() actually returned a Shape object, so I did convert to using var.
Another benefit falls where you said it might be questionable. var data = GetData(). Let’s say you had var data = repo.GetData() and it returned an object of type MyData where MyData is in a completely different name space. Using var actually saves me an using for a single class (or having to type out the namespace before the class to avoid the namespace).
Hopefully that all made sense.
JV said,
Wrote on June 25, 2008 @ 3:48 pm
I prefer to see “var” as a wolf in sheep clothes, some day it will bite you in your ase because of the issues you meant last.
Usings have more usages then just taking up space btw, it shows you your depencies and that’s very usefull!
Josh Stodola said,
Wrote on June 25, 2008 @ 5:29 pm
To hell with var. If you don’t like redundancy in your variable declarations, be a man and switch to the .NET superior: VB.