在与同事讨论了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确实保持强类型，但问题是，在定义中不立即显示类型是否危险，当重载意味着当你无意中将错误的类型传递给方法时，编译器可能不会发出错误，这种情况会被放大。
来自c#团队的高级软件设计工程师Eric Lippert:
为什么引入var关键字?
There are two reasons, one which
exists today, one which will crop up
in 3.0.
The first reason is that this code is
incredibly ugly because of all the
redundancy:
Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();
And that's a simple example – I've
written worse. Any time you're forced
to type exactly the same thing twice,
that's a redundancy that we can
remove. Much nicer to write
var mylists = new Dictionary<string,List<int>>();
and let the compiler figure out what
the type is based on the assignment.
Second, C# 3.0 introduces anonymous
types. Since anonymous types by
definition have no names, you need to
be able to infer the type of the
variable from the initializing
expression if its type is anonymous.
我特别强调。整篇文章，c# 3.0仍然是静态类型的，真的!，以及随后的系列相当不错。
这就是var的作用。其他用途可能就没这么好用了。任何与JScript、VBScript或动态类型的比较都是胡扯。再次注意，var是为了使某些其他特性在. net中工作而必需的。
好吧，这个问题会一直固执己见，但我会试着给出我的观点-尽管我认为我的观点是如此混乱，你可能不会从中得到什么。
首先——有匿名类型，为此你需要使用“var”关键字来分配一个匿名类型作为类的对象——这里没有太多的讨论，“var”是必要的。
然而，对于更简单的类型，如int型、长型、字符串型等等，我倾向于输入适当的类型。主要是因为它有点像“懒人的工具”，我在这里看不到太多的好处，很少的按键和它可能带来的困惑，这是不值得的。特别是浮点数的各种类型(浮点数、双精度数、十进制数)使我感到困惑，因为我对字面量中的后缀不坚定——我喜欢在源代码中看到类型。
话虽如此，如果类型更复杂和/或它显式地重复在赋值的右侧，我倾向于大量使用var。这可以是一个List<string>或etc，例如:
var list = new List<string>();
在这种情况下，我认为没有必要重复类型两次——特别是当您开始更改代码和类型更改时——泛型类型可能会变得越来越复杂，因此必须更改它们两次只是一种痛苦。当然，如果你希望针对IList<string>编码，那么你必须显式地命名类型。
简而言之，我做了以下事情:
当类型很短或不能脱离上下文读取时，显式地命名类型
在必要时使用var(废话)
当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')时，我们阻止了对使用这种语法定义的变量的赋值。
我认为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。
