在与同事讨论了c# 3中var关键字的使用后，我想知道人们对通过var适当使用类型推断的看法是什么?
例如，我很懒地在有问题的情况下使用var，例如:-
foreach(var item in someList) { // ... } // Type of 'item' not clear.
var something = someObject.SomeProperty; // Type of 'something' not clear.
var something = someMethod(); // Type of 'something' not clear.
var更合法的用法如下:-
var l = new List<string>(); // Obvious what l will be.
var s = new SomeClass(); // Obvious what s will be.
有趣的是，LINQ似乎是一个灰色区域，例如:-
var results = from r in dataContext.SomeTable
select r; // Not *entirely clear* what results will be here.
结果很明显，因为它将是一个实现IEnumerable的类型，但它并不完全明显，与var声明一个新对象的方式相同。
当涉及到对象的LINQ时，情况就更糟了，例如:-
var results = from item in someList
where item != 3
select item;
这并不比等价的foreach(var item in someList){//…}相当于。
这里有一个关于类型安全的真正问题——例如，如果我们将该查询的结果放在一个接受IEnumerable<int>和IEnumerable<double>的重载方法中，调用者可能会无意中传入错误的类型。
Var确实保持强类型，但问题是，在定义中不立即显示类型是否危险，当重载意味着当你无意中将错误的类型传递给方法时，编译器可能不会发出错误，这种情况会被放大。
我们采用了“为人编写代码，而不是为机器编写代码”的理念，基于这样的假设:在维护模式中花费的时间要比在新的开发模式中花费的时间长好几倍。
对我来说，这就排除了编译器“知道”变量是什么类型的说法——当然，你不可能第一次就写出无效的代码，因为编译器会阻止你的代码编译，但是当下一个开发人员在6个月的时间里阅读代码时，他们需要能够推断出变量做得正确或不正确的地方，并快速确定问题的原因。
因此,
var something = SomeMethod();
在我们的编码标准中是不合法的，但在我们的团队中鼓励这样做，因为它增加了可读性:
var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
DoWork( item );
}
在IEnumerable<int>和IEnumerable<double>之间的比较中，你不需要担心-如果你传递了错误的类型，你的代码无论如何都不会编译。
不需要考虑类型安全，因为var不是动态的。这只是编译器的魔法，任何类型不安全的调用都会被捕获。
Linq绝对需要Var:
var anonEnumeration =
from post in AllPosts()
where post.Date > oldDate
let author = GetAuthor( post.AuthorId )
select new {
PostName = post.Name,
post.Date,
AuthorName = author.Name
};
现在看看智能感知中的anonEnumeration，它会显示类似IEnumerable<'a>
foreach( var item in anonEnumeration )
{
//VS knows the type
item.PostName; //you'll get intellisense here
//you still have type safety
item.ItemId; //will throw a compiler exception
}
c#编译器非常聪明——单独生成的anon类型如果它们的属性匹配，将具有相同的生成类型。
除此之外，只要你有智能感知，在上下文清楚的地方使用var是有意义的。
//less typing, this is good
var myList = new List<UnreasonablyLongClassName>();
//also good - I can't be mistaken on type
var anotherList = GetAllOfSomeItem();
//but not here - probably best to leave single value types declared
var decimalNum = 123.456m;
Apart from readability concerns, there is one real issue with the use of 'var'. When used to define variables that are assigned to later in the code it can lead to broken code if the type of the expression used to initialize the variable changes to a narrower type. Normally it would be safe to refactor a method to return a narrower type than it did before: e.g. to replace a return type of 'Object' with some class 'Foo'. But if there is a variable whose type is inferred based on the method, then changing the return type will mean that this variable can longer be assigned a non-Foo object:
var x = getFoo(); // Originally declared to return Object
x = getNonFoo();
所以在这个例子中，改变getFoo的返回类型会使getNonFoo的赋值变为非法。
如果getFoo和它的所有用途都在同一个项目中，这不是什么大问题，但如果getFoo在一个库中供外部项目使用，如果他们像这样使用'var'，你就不能确保缩小返回类型不会破坏某些用户的代码。
正是由于这个原因，当我们在Curl编程语言中添加类似的类型推断特性(在Curl中称为'def')时，我们阻止了对使用这种语法定义的变量的赋值。
