var (C# Reference)
Beginning in Visual C# 3.0, variables that are declared at method scope can have an implicit type var. An implicitly typed local variable is strongly typed just as if you had declared the type yourself, but the compiler determines the type. The following two declarations of i are functionally equivalent:
var i = 10; // implicitly typed int i = 10; //explicitly typed
For more information, see Implicitly Typed Local Variables (C# Programming Guide) and Type Relationships in LINQ Query Operations (C#).
The following example shows two query expressions. In the first expression, the use of var is permitted but is not required, because the type of the query result can be stated explicitly as an IEnumerable<string>. However, in the second expression, var must be used because the result is a collection of anonymous types, and the name of that type is not accessible except to the compiler itself. Note that in Example #2, the foreach iteration variable item must also be implicitly typed.
// Example #1: var is optional because // the select clause specifies a string string[] words = { "apple", "strawberry", "grape", "peach", "banana" }; var wordQuery = from word in words where word[0] == 'g' select word; // Because each element in the sequence is a string, // not an anonymous type, var is optional here also. foreach (string s in wordQuery) { Console.WriteLine(s); } // Example #2: var is required because // the select clause specifies an anonymous type var custQuery = from cust in customers where cust.City == "Phoenix" select new { cust.Name, cust.Phone }; // var must be used because each item // in the sequence is an anonymous type foreach (var item in custQuery) { Console.WriteLine("Name={0}, Phone={1}", item.Name, item.Phone); }
is slightly less readable than
var s = new Blah.Blah.Blah.Blah.Something<Blah.Blah.Blah.Blah.SubTypeA,Blah.Blah.Blah.Blah.SubTypeB>()
especially when you are working with the long names VS creates as default,
i only use var to declare local variable that are created from a clear and visible source such as a Where<> functions that uses Linq to build generic interfaces that are used breifly and disposed of after use
And that's a good thing. The compiler will then only consider what it needs to know about IMemberProvider and no more - so your attention is focussed on the fact that you have some sort of collection of members, rather than specifically a List<IMember>. Perhaps readability is the wrong word, it certainly improves understandability of code because it highlights intent over implementation detail.
- 12/24/2009
- Julia_H
"However, the use of var does have at least the potential to make your code more difficult to understand for other developers. For that reason, the C# documentation generally uses var only when it is required."
And now, explain to me how this is more readable to you:
public void DoStuff(IMemberProvider memberProvider)
{ var members = memberProvider.RetreiveMembers();
Console.WriteLine(members.ToString());
... Do more stuff with members.
}
All we do know, is that it is most likely something that contains members.
(unless you have the entire project AND uses an IDE... suddenly code becomes much more painfull to read since you need to interact with your IDE to understand it)...
I can at all time except the "var" keyword if its used as:
public void DoStuff(IMemberProvider memberProvider)
{ var members = new List<IMember>();
memberProvider.AddMembers(members);
... Do more stuff.
}
(like most people reading English)...
or maybe you prefere naming conventions as:
public void DoStuff(IMemberProvider memberProvider)
{ var listOfIMemberMembers = memberProvider.RetreiveMembers();
Console.WriteLine(listOfIMemberMembers.ToString());
... Do more stuff with listOfIMemberMembers.
var listOfIMemberAdmins = memberProvider.RetreiveAdministrators();
Console.WriteLine(listOfIMemberAdmins .ToString());... Do more stuff with listOfIMemberAdmins.}
I will at ANY time prefer the following dumb of code, and I will ALWAYS claim that is more readable that any of the above...:
public void DoStuff(IMemberProvider memberProvider)
{ List<IMember> members = memberProvider.RetreiveMembers();
Console.WriteLine(members.ToString());
... Do more stuff with members.
List<IMember> admins = memberProvider.RetreiveAdministrators();
Console.WriteLine(members.ToString());... Do more stuff with members.}
(Also keep in mind 'var' was introduced BECAUSE it was needed for anonumous types)
- 9/24/2009
- wesmcclure
As I just learned 'var' can slow down tests-driven development (TDD) in some cases. This can happen when you write assertions against a 'var' but the value of the 'var' is assigned the return value of a method that is not yet implemented.
For more details please see http://manfredlange.blogspot.com/2009/03/implicit-typing-can-make-tdd-harder.html
- 3/14/2009
- Manfred Lange
The following code will fail with an error on the second line:
var MyVar = 500;
MyVar = "Change To String"; // This line fails with message: "Cannot convert INT to STRING"
Other languages that have types similar to C#'s implementation dont have this restriction.
- 2/6/2008
- LyalinDotCom
- 11/14/2008
- AnnaDault
- 10/15/2008
- Aman Shaikh
- 9/26/2008
- Anil Mujagic
- 9/26/2008
- Anil Mujagic
- 7/18/2008
- Thomas Lee
I don't think this thread should be deleted. As far as I can see he didn't understand the concept, so he stated that. I can ensure you that it helped me out understanding the concept of var, and with his statement it helped me even more. So thank you LyalinDotCom for showing us how it doesn't work, and thanks jopincar for telling us why it doesn't work. And sure that LyalinDotCom now gets the idea about the var keyword.
- 7/18/2008
- ESTAN
This whole thread should be deleted as it is clear the original poster does not understand the concept of this new feature. This is not a restriction but indeed a very good design.
- 7/15/2008
- ejkitchen
- 2/20/2008
- jopincar