Any advantage to use implicitly type var

I am not accustomed to use Var implicitly typed variable. Anyone can let me 开发者_运维百科know the advantage to use such variable?

Annonymous types:

var person = new { Name = "John", Surname = "Doe" };

One thing is that it's a short hand for long types...Such as:

List<Dictionary<string, object>> myList = getList();

Can be simplified to:

var myList = getList();

Under normal use, 'var' is entirely optional and equivalent to manually specifying the type. See here.

However, the 'var' keyword is needed for anonymous types, which I've normally used in conjunction with LINQ.

I specifically find it much easier to read this:

foreach(var dbitem in context.usp_GetUserAndAccountData())
{
    txtUserName.Text = dbitem.UserName;
    // ...
}

Than this:

foreach(ISingleResult<usp_GetUserAndAccountDataResult> dbitem in context.usp_GetUserAndAccountData())
{
    txtUserName.Text = dbitem.UserName;
    // ...
}

For me, regardless of what I explicitly define dbitem, I'll still do the same actions; so var here is priceless!
And the beauty of it all is that IntelliSense will still list you all the members of the expected type on the other end (such as UserName in my example).

Better code readability. Especially used with constructors and long type name:

var anArray = new String[3];
var iStream = new InputStream(...);
var dict = new Dictionary<string, int>();

Just be mindful that using var is not always what it seems (though mostly is). An example is this:

dataList is a DataList control on a webform

foreach (var item in dataList.Items)
{
    // item is of type System.Object
}

foreach (DataListItem item in dataList.Items)
{
    // item is of type DataListItem
}

I believe that it was created for the purpose of anonymous types (ala Kugels example):

var person = new { Name = "John", Surname = "Doe" };

However since I discovered it I have to admit I have found it quite useful in day-to-day use when dealing with longer type names, for example:

var aaa = new Dictionary<string, List<ReallyLongTypeName>>();
// vs
Dictionary<string, List<ReallyLongTypeName>> aaa = new Dictionary<string, List<ReallyLongTypeName>>();

Another side effect is that type names can change (or be replaced with other types), but code that uses var wont' break, for example:

var item = this.GetItem();
this.Name = item.Name;
this.Age = item.Age;

As long as the return value from GetItem always has a property Name and a property Age (which are compatible with the properties on this) then GetItems can return an entirely different object and the above code will still compile. (But be careful - existing compiled assemblies can't use the same trick!)

Apart from the other answers, to me a real advantage is when dealing with external code, to decouple the variable type from the actual method signature.

Consider this interface:

public interface IFoo
{
   List<Foo> GetSomething();
}

And say you have two lines of code:

List<Foo> foos = fooRepo.GetSomething();
var foos2 = fooRepo.GetSomething();

Same result for above two lines. (List<Foo> returned).

Now if changed the interface:

public interface IFoo
{
   Dictionary<bool,Foo> GetSomething();
}

The first line would now throw a compiler error, the second would not:

List<Foo> foos = fooRepo.GetSomething(); // error - can't convert from Dictionary<bool,Foo> to List<Foo>
var foos2 = fooRepo.GetSomething(); // works!

This is really handy when working with repositories/other projects where interface contracts/method signatures can change.

Yes you still have to recompile the classes, but you don't have to go back and change all the code that referenced the old return type.