在与同事讨论了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长大的人一样，我习惯于查看类型声明的左侧。除非迫不得已，我是不会看右边的。在任何旧的声明中使用var都让我一直这样做，我个人觉得不舒服。
Those saying 'it doesn't matter, use what you're happy with' are not seeing the whole picture. Everyone will pick up other people's code at one point or another and have to deal with whatever decisions they made at the time they wrote it. It's bad enough having to deal with radically different naming conventions, or - the classic gripe - bracing styles, without adding the whole 'var or not' thing into the mix. The worst case will be where one programmer didn't use var and then along comes a maintainer who loves it, and extends the code using it. So now you have an unholy mess.
标准是一件好事，因为它们意味着你更有可能捡起随机代码，并能够快速地理解它。不同的东西越多，就越难。而转移到“无处不在的var”风格会有很大的不同。
I don't mind dynamic typing, and I don't mind implict typing - in languages that are designed for them. I quite like Python. But C# was designed as a statically explicitly-typed language and that's how it should stay. Breaking the rules for anonymous types was bad enough; letting people take that still further and break the idioms of the language even more is something I'm not happy with. Now that the genie is out of the bottle, it'll never go back in. C# will become balkanised into camps. Not good.
我认为人们不理解var关键字。
他们把它和Visual Basic / JavaScript关键字搞混了，
这完全是另一回事。
许多人认为var关键字意味着
弱类型(或动态类型)，而实际上c#是并保持强类型。
如果你在javascript中考虑这个:
var something = 5;
你可以:
something = "hello";
在c#中，编译器会从第一条语句中推断出类型，
导致“int”类型的东西，因此会产生第二条语句
在异常中。
人们只需要明白，使用var关键字并不意味着
动态类型，然后决定var关键字的使用程度，
知道它对于将要编译的内容绝对没有区别。
当然var关键字的引入是为了支持匿名类型，
但如果你看这个:
LedDeviceController controller = new LedDeviceController("172.17.0.1");
这是非常非常冗长的，我相信这是一样可读的，如果不是更多:
var controller = new LedDeviceController("172.17.0.1");
结果是完全相同的，所以是的，我在我的代码中使用它
更新:
也许，只是也许……他们应该用另一个关键词，
那我们就不会有这样的讨论了……也许是“推断”关键字而不是“var”
好吧，这个问题会一直固执己见，但我会试着给出我的观点-尽管我认为我的观点是如此混乱，你可能不会从中得到什么。
首先——有匿名类型，为此你需要使用“var”关键字来分配一个匿名类型作为类的对象——这里没有太多的讨论，“var”是必要的。
然而，对于更简单的类型，如int型、长型、字符串型等等，我倾向于输入适当的类型。主要是因为它有点像“懒人的工具”，我在这里看不到太多的好处，很少的按键和它可能带来的困惑，这是不值得的。特别是浮点数的各种类型(浮点数、双精度数、十进制数)使我感到困惑，因为我对字面量中的后缀不坚定——我喜欢在源代码中看到类型。
话虽如此，如果类型更复杂和/或它显式地重复在赋值的右侧，我倾向于大量使用var。这可以是一个List<string>或etc，例如:
var list = new List<string>();
在这种情况下，我认为没有必要重复类型两次——特别是当您开始更改代码和类型更改时——泛型类型可能会变得越来越复杂，因此必须更改它们两次只是一种痛苦。当然，如果你希望针对IList<string>编码，那么你必须显式地命名类型。
简而言之，我做了以下事情:
当类型很短或不能脱离上下文读取时，显式地命名类型
在必要时使用var(废话)
当var(在我看来)不影响可读性时，使用它来偷懒
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.
