在与同事讨论了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 something = someMethod(); // Type of 'something' not clear <-- not to the compiler!
你仍然对“某事”有完全的智能感知，对于任何不明确的情况，你都有单元测试，对吗?(是吗?)
它不是varchar，也不是dim，当然也不是动态或弱类型。它像这样阻止疯狂的人:
List<somethinglongtypename> v = new List<somethinglongtypename>();
把这些杂乱的思想归纳为:
var v = new List<somethinglongtypename>();
不错，但不如:
v = List<somethinglongtypename>();
但这就是布的作用。
我们采用了“为人编写代码，而不是为机器编写代码”的理念，基于这样的假设:在维护模式中花费的时间要比在新的开发模式中花费的时间长好几倍。
对我来说，这就排除了编译器“知道”变量是什么类型的说法——当然，你不可能第一次就写出无效的代码，因为编译器会阻止你的代码编译，但是当下一个开发人员在6个月的时间里阅读代码时，他们需要能够推断出变量做得正确或不正确的地方，并快速确定问题的原因。
因此,
var something = SomeMethod();
在我们的编码标准中是不合法的，但在我们的团队中鼓励这样做，因为它增加了可读性:
var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
DoWork( item );
}
Var，在我看来，在c#中是一个很好的东西。任何这样类型的变量仍然是强类型的，但是它从赋值函数的右边得到它的类型。因为类型信息在右侧可用，在大多数情况下，也必须在左侧输入它是不必要的和过于冗长的。我认为这在不降低类型安全性的情况下显著提高了可读性。
From my perspective, using good naming conventions for variables and methods is more important from a readability perspective than explicit type information. If I need the type information, I can always hover over the variable (in VS) and get it. Generally, though, explicit type information shouldn't be necessary to the reader. For the developer, in VS you still get Intellisense, regardless of how the variable is declared. Having said all of that, there may still be cases where it does make sense to explicitly declare the type -- perhaps you have a method that returns a List<T>, but you want to treat it as an IEnumerable<T> in your method. To ensure that you are using the interface, declaring the variable of the interface type can make this explicit. Or, perhaps, you want to declare a variable without an initial value -- because it immediately gets a value based on some condition. In that case you need the type. If the type information is useful or necessary, go ahead and use it. I feel, though, that typically it isn't necessary and the code is easier to read without it in most cases.
