摘自CodingHorror关于这一问题的文章:

不幸的是，你和其他人都错了。虽然我同意你的观点，冗余不是一件好事，但解决这个问题的更好方法应该是这样做:

MyObject m = new();

或者如果你传递参数:

Person p = new("FirstName"， "LastName ");

在创建新对象时，编译器从左边推断类型，而不是右边。这比“var”有其他优点，因为它也可以在字段声明中使用(还有其他一些领域，它也可能有用，但我不会在这里讨论)。

最后，这并不是为了减少冗余。不要误解我，“var”在c#中对于匿名类型/投影是非常重要的，但是这里的使用是非常错误的(我已经说了很长很长一段时间了)，因为你混淆了正在使用的类型。输入两次太频繁了，但是声明0次就太少了。

2008年6月20日上午08:00,c#mvp

我想如果你主要关心的是必须少打字——那么没有任何争论会动摇你使用它。

如果你只是一个查看代码的人，那么谁在乎呢?否则，在这种情况下:

var people = Managers.People

没关系，但在这种情况下:

var fc = Factory.Run();

它使我的大脑从代码的“英文”开始形成的任何即时类型推断短路。

否则，就用你最好的判断和编程“礼貌”来对待那些可能不得不为你的项目工作的人。

你不需要写出类型名，这不会降低性能，因为类型是在编译时解析的。

我想这取决于你的看法。我个人从来没有因为var“误用”而理解一段代码有任何困难，我的同事和我都经常使用它。(我同意智能感知在这方面是一个巨大的帮助。)我欢迎它作为一种消除重复性麻烦的方法。

毕竟，如果语句像

var index = 5; // this is supposed to be bad

var firstEligibleObject = FetchSomething(); // oh no what type is it
                                            // i am going to die if i don't know

如果真的无法处理，没有人会使用动态类型语言。

考虑到智能感知现在是多么强大，我不确定var是否比在一个类中拥有成员变量或在一个方法中定义在可见屏幕区域之外的局部变量更难阅读。

如果你有一行代码，比如

IDictionary<BigClassName, SomeOtherBigClassName> nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

Is比以下更容易或更难读:

var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

我认为VAR的关键是只在适当的地方使用它，即在Linq中做一些方便的事情(可能在其他情况下)。

如果你有一个类型的东西，那么你应该使用它-不这样做是简单的懒惰(与创造性的懒惰相反，这通常是被鼓励的-优秀的程序员往往非常努力地工作，懒惰，可以被认为是最初的东西的来源)。

全面禁止就像滥用这种结构一样糟糕，但确实需要一个合理的编码标准。

另一件需要记住的事情是，它不是VB类型变量，因为它不能改变类型——它是一个强类型变量，它只是类型是推断出来的(这就是为什么有人会认为在foreach中使用它不是不合理的，但出于可读性和可维护性的原因，我不同意)。

我怀疑这个会一直持续下去(-:

梅菲

我尽可能使用var。

如果你的代码写得好，局部变量的实际类型并不重要(例如，良好的变量名，注释，清晰的结构等)。