在与同事讨论了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确实保持强类型，但问题是，在定义中不立即显示类型是否危险，当重载意味着当你无意中将错误的类型传递给方法时，编译器可能不会发出错误，这种情况会被放大。
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')时，我们阻止了对使用这种语法定义的变量的赋值。
有时编译器也能比开发人员“更好”地推断出需要什么——至少开发人员不了解他所使用的api需要什么。
例如-当使用linq时:
示例1
Func<Person, bool> predicate = (i) => i.Id < 10;
IEnumerable<Person> result = table.Where(predicate);
示例2
var predicate = (Person i) => i.Id < 10;
var result = table.Where(predicate);
在上面的代码中-假设一个是使用Linq到Nhibernate或Linq到SQL，示例1将
返回Person对象的整个结果集，然后在客户端进行筛选。
然而，示例2将在服务器上执行查询(例如在Sql server上使用Sql)，因为编译器足够聪明，可以计算出Where函数应该采用表达式>而不是Func。
示例1中的结果在返回IEnumerable时也不能在服务器上进一步查询，而在示例2中，编译器可以计算出结果是否应该是IQueryable而不是IEnumerable
我认为var的使用应该与明智选择的变量名称相结合。
我在foreach语句中使用var没有问题，前提是它不是这样的:
foreach (var c in list) { ... }
如果是这样的话:
foreach (var customer in list) { ... }
．.． 这样，阅读代码的人就更有可能理解什么是“列表”。如果您可以控制列表变量本身的名称，那就更好了。
这同样适用于其他情况。这是非常无用的:
var x = SaveFoo(foo);
．.． 但这是有道理的:
var saveSucceeded = SaveFoo(foo);
各有各的，我想。我发现自己这样做，简直是疯了:
var f = (float)3;
我需要一个12步的var程序。我叫Matt，我(ab)使用var。
在边缘情况下肯定会有分歧，但我可以告诉你我的个人指导方针。
当我决定使用var时，我看看这些标准:
变量的类型(对人来说)从上下文是很明显的
变量的确切类型(对人类来说)并不是特别相关。
[例如，你可以弄清楚算法在做什么，而不用关心你使用的是哪种容器]
类型名非常长，会影响代码的可读性(提示:通常是泛型)
相反，这些情况会促使我不使用var:
类型名称相对较短且易于阅读(提示:通常不是泛型)
从初始化式的名称来看，类型并不明显
确切的类型对于理解代码/算法非常重要
在类层次结构上，当一个人不能很容易地知道正在使用层次结构的哪个级别时
最后，我永远不会使用var的本机值类型或相应的可空<>类型(int，十进制，字符串，十进制?,……)。这里有一个隐含的假设，如果你使用var，一定有一个“原因”。
这些都是指导方针。你还应该考虑你同事的经验和技能，算法的复杂性，变量的寿命/范围，等等。
大多数时候，没有完美的正确答案。或者，这并不重要。
[编辑:删除重复的子弹]
