在与同事讨论了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确实保持强类型，但问题是，在定义中不立即显示类型是否危险，当重载意味着当你无意中将错误的类型传递给方法时，编译器可能不会发出错误，这种情况会被放大。
局部变量可以被赋予一个推断的var“类型”，而不是一个显式的类型。关键字var指示编译器从初始化语句右边的表达式推断变量的类型。
// z被编译为int类型
var z = 100;
// s被编译为下面的字符串
var s = "Hello";
// a被编译为int[]
var a = new[] { 0, 1, 2 };
// expr被编译为IEnumerable
//或者IQueryable
var expr =
from c in customers
where c.City == "London"
select c;
// anon被编译为匿名类型
var anon = new { Name = "Terry", Age = 34 };
// list被编译为list
var list = new List<int>();
var can only be used when a local variable is declared and initialized in the same statement; the variable cannot be initialized to null, or to a method group or an anonymous function.
Var不能在类范围内的字段上使用。
使用var声明的变量不能在初始化表达式中使用。换句话说，这个表达式是合法的:int i = (i = 20);但是这个表达式会产生一个编译时错误:var I = (I = 20);
多个隐式类型变量不能在同一个语句中初始化。
如果一个名为var的类型在作用域中，那么var关键字将解析为该类型名称，并且不会被视为隐式类型局部变量声明的一部分。
在边缘情况下肯定会有分歧，但我可以告诉你我的个人指导方针。
当我决定使用var时，我看看这些标准:
变量的类型(对人来说)从上下文是很明显的
变量的确切类型(对人类来说)并不是特别相关。
[例如，你可以弄清楚算法在做什么，而不用关心你使用的是哪种容器]
类型名非常长，会影响代码的可读性(提示:通常是泛型)
相反，这些情况会促使我不使用var:
类型名称相对较短且易于阅读(提示:通常不是泛型)
从初始化式的名称来看，类型并不明显
确切的类型对于理解代码/算法非常重要
在类层次结构上，当一个人不能很容易地知道正在使用层次结构的哪个级别时
最后，我永远不会使用var的本机值类型或相应的可空<>类型(int，十进制，字符串，十进制?,……)。这里有一个隐含的假设，如果你使用var，一定有一个“原因”。
这些都是指导方针。你还应该考虑你同事的经验和技能，算法的复杂性，变量的寿命/范围，等等。
大多数时候，没有完美的正确答案。或者，这并不重要。
[编辑:删除重复的子弹]
我广泛使用var。有人批评这降低了代码的可读性，但没有证据支持这种说法。
Admittedly, it may mean that it's not clear what type we are dealing with. So what? This is actually the point of a decoupled design. When dealing with interfaces, you are emphatically not interested in the type a variable has. var takes this much further, true, but I think that the argument remains the same from a readability point of view: The programmer shouldn't actually be interested in the type of the variable but rather in what a variable does. This is why Microsoft also calls type inference “duck typing.”
当我用var声明变量时，它会做什么呢?简单，智能感知让它做什么它就做什么。任何关于c#的推理都忽略了IDE，这是不现实的。实际上，每个c#代码都是在支持智能感知的IDE中编写的。
如果我使用了一个var声明的变量，并对变量的用途感到困惑，那么我的代码就有根本性的问题。Var不是原因，它只是使症状可见。不要责怪送信的人。
现在，c#团队发布了一个编码指南，声明var应该只用于捕获创建匿名类型的LINQ语句的结果(因为在这里，我们没有真正的替代var的方法)。去他的。只要c#团队没有给我一个合理的论证，我就会忽略它，因为在我的专业和个人观点中，这纯粹是胡扯。(抱歉;我找不到相关指南的链接。)
Actually, there are some (superficially) good explanations on why you shouldn't use var but I still believe they are largely wrong. Take the example of “searchabililty”: the author claims that var makes it hard to search for places where MyType is used. Right. So do interfaces. Actually, why would I want to know where the class is used? I might be more interested in where it is instantiated and this will still be searchable because somewhere its constructor has to be invoked (even if this is done indirectly, the type name has to be mentioned somewhere).
