我认为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。

在我们的办公室，我们的CTO已经明确禁止使用var关键字，原因与您所陈述的相同。

我个人认为var的使用只在new对象声明中有效，因为对象的类型在语句本身就很明显。

对于LINQ查询，您可以将结果解析为:

IEnumerable<TypeReturnedBySelectObject>

当我开始使用var关键字时，我也有同样的担忧。 然而，随着时间的推移，我已经习惯了它，不打算回到显式变量类型。 Visual Studio的编译器\智能感知在使隐式类型变量的工作更容易方面做得非常好。

我认为遵循正确的命名约定可以帮助您更好地理解代码，而不是显式键入。

这似乎是类似于“我应该在变量名中使用前缀吗?”这样的问题。 坚持使用好的变量名，让编译器考虑变量类型。

有人不喜欢批评var..所有答案downmodded..哦. .

@Jon Limjap: 我知道。:)我的意思是可读性被降级了，就像在VB6一样。我不喜欢依靠智能感知来确定给定变量的类型。我希望能单独用源代码求出它。

命名惯例也没用——我已经用好名字了。我们要回到前缀时代吗?

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

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

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

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

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

梅菲

var很困难的一个具体情况是:离线代码审查，特别是在纸上完成的代码审查。

你不能依赖鼠标的移动。

我仍然认为var在某些情况下可以使代码更具可读性。如果我有一个带有Orders属性的Customer类，我想把它赋值给一个变量，我只需要这样做:

var orders = cust.Orders;

我不在乎顾客。Orders是IEnumerable<Order>， ObservableCollection<Order>或BindingList<Order> -我想要的只是将该列表保存在内存中，以便稍后对其进行迭代或获取其计数或其他内容。

将上述声明与:

ObservableCollection<Order> orders = cust.Orders;

对我来说，类型名只是噪音。如果我回头决定改变客户的类型。沿着轨道的订单(从ObservableCollection<Order>到IList<Order>)，然后我也需要改变声明-如果我在第一个地方使用var，我就不必这样做。

@erlando，出于好奇，为什么你需要知道变量的类型看源代码?

在我的实践中，我发现变量类型只在我在代码中使用它的时候对我来说是重要的。

如果我试图做一些不适当的操作在某些evar编译器欣然给我一个错误\警告。

我真的不关心someVar有什么类型，如果我明白为什么它被使用在给定的上下文中。

我广泛使用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).

@aku:代码审查就是一个例子。另一个例子是重构场景。

基本上我不想用我的鼠标去打字。它可能不可用。

我不明白这有什么大不了的。

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>();

但这就是布的作用。

@erlando,

谈到重构，通过将新类型的实例分配给一个变量而不是在多个地方更改它来更改变量类型似乎要容易得多，不是吗?

至于代码审查，我认为var关键字没有大问题。在代码审查期间，我更喜欢检查代码逻辑而不是变量类型。当然，可能会有开发人员可以使用不合适的类型的情况，但我认为这种情况的数量是如此之少，它不会成为我停止使用var关键字的原因。

我重复一下我的问题。为什么变量类型对您很重要?

这是个人品味的问题。当您习惯了动态类型的语言后，所有关于变量类型的烦恼都消失了。也就是说，如果你开始喜欢他们(我不确定是不是每个人都可以，但我喜欢)。

c#的var非常酷，因为它看起来像动态类型，但实际上是静态类型——编译器会强制正确使用。

变量的类型并不是那么重要(这在前面已经说过了)。从上下文(它与其他变量和方法的交互)和它的名称来看，它应该相对清晰——不要期望customerList包含int…

我还在等着看我的老板对这件事的看法——我得到了一个全面的“允许”，可以在3.5中使用任何新的结构，但是我们将如何维护呢?

在IEnumerable<int>和IEnumerable<double>之间的比较中，你不需要担心-如果你传递了错误的类型，你的代码无论如何都不会编译。

不需要考虑类型安全，因为var不是动态的。这只是编译器的魔法，任何类型不安全的调用都会被捕获。

Linq绝对需要Var:

var anonEnumeration =
    from post in AllPosts()
    where post.Date > oldDate
    let author = GetAuthor( post.AuthorId )
    select new { 
        PostName = post.Name, 
        post.Date, 
        AuthorName = author.Name
    };

现在看看智能感知中的anonEnumeration，它会显示类似IEnumerable<'a>

foreach( var item in anonEnumeration ) 
{
    //VS knows the type
    item.PostName; //you'll get intellisense here

    //you still have type safety
    item.ItemId;   //will throw a compiler exception
}

c#编译器非常聪明——单独生成的anon类型如果它们的属性匹配，将具有相同的生成类型。

除此之外，只要你有智能感知，在上下文清楚的地方使用var是有意义的。

//less typing, this is good
var myList = new List<UnreasonablyLongClassName>();

//also good - I can't be mistaken on type
var anotherList = GetAllOfSomeItem();

//but not here - probably best to leave single value types declared
var decimalNum = 123.456m;

我分裂var的所有地方，唯一有问题的地方对我来说是内部短类型，例如，我更喜欢int I = 3;除以var I = 3;

@Keith -

在你们的比较中 IEnumerable < int > IEnumerable<double>你不需要 担心——如果你传递了错误的类型 您的代码无论如何都无法编译。

这并不完全正确——如果一个方法同时重载到IEnumerable<int>和IEnumerable<double>，那么它可能会无声地将意外推断的类型(由于程序中的其他一些更改)传递给错误的重载，从而导致不正确的行为。

我想问题是这种情况出现的可能性有多大!

我猜部分问题是var给给定的声明增加了多少混乱——如果不清楚某个东西是什么类型(尽管它是强类型的，编译器完全理解它是什么类型)，有人可能会掩盖一个类型安全错误，或者至少需要更长的时间来理解一段代码。

我在以下情况下使用var:

当我不得不(结果是匿名的) 当类型与代码在同一行时，例如: var emp = new Employee();

很明显，我们需要一个Employee对象(因为我们正在创建一个新的Employee对象)，那么如何呢

Employee emp = new Employee() any more obvious?

当类型无法推断时，我不使用var。

var emp = GetEmployee();

因为返回类型不是很明显(是在Employee对象上，还是在IEmployee对象上，还是在与Employee对象完全没有关系的对象上，等等?)

在转换到3.0和3.5框架之后，我了解了这个关键字，并决定尝试一下。在提交任何代码之前，我意识到它似乎是向后的，就像回到ASP语法一样。所以我决定戳一下高层，看看他们怎么想。

他们说去吧，我就用了。

也就是说，我避免在类型需要一些调查的地方使用它，就像这样:

var a = 公司。获取记录（）;

现在它可能只是一个个人的事情，但我立即不能看，并确定如果它是一个记录对象的集合或一个字符串数组表示记录的名称。无论哪种情况，我认为显式声明在这种情况下是有用的。

我同意马特·汉密尔顿的观点。

当使用好的变量名时，Var可以使您的代码更具可读性和可理解性。但是，如果使用不当，var也会使您的代码像Perl一样难以阅读和理解。

一个var的好的和坏的用法列表也不会有太大的帮助。这是一个常识问题。更大的问题是可读性和可写性。许多开发者并不关心他们的代码是否具有可读性。他们只是不想打那么多。就我个人而言，我是一个读，写，写的人。

Kronoz -在这种情况下(两者都重载)会有问题吗?如果你有两个不同类型的重载，本质上你会说任何一个都可以被传递，做同样的事情。

不应该有两个重载根据传递的类型执行完全不同的操作。

虽然在这种情况下您可能会感到困惑，但它仍然是完全类型安全的，只是有人调用了错误的方法。

I don't understand why people start debates like this. It really serves no purpose than to start flame wars at then end of which nothing is gained. Now if the C# team was trying to phase out one style in favor of the other, I can see the reason to argue over the merits of each style. But since both are going to remain in the language, why not use the one you prefer and let everybody do the same. It's like the use of everybody's favorite ternary operator: some like it and some don't. At the end of the day, it makes no difference to the compiler.

这就像和你的兄弟姐妹争论你最喜欢的父母是谁:除非他们离婚了，否则没关系!

静态类型是关于契约的，而不是源代码。这里的想法是需要将静态信息放在“应该”是一个小方法的单行上。一般指南建议每个方法不要超过25行。

如果一个方法足够大，以至于您无法跟踪该方法中的单个变量，那么您做错了其他事情，这将使任何对var的批评相形见绌。

实际上，var的一个重要论点是它可以使重构更简单，因为你不再需要担心你的声明过于严格(例如，当你应该使用IList<>或IEnumerable<>时，你使用了List<>)。您仍然需要考虑新的方法签名，但至少不必返回并更改声明来匹配。

我发现使用var关键字实际上使代码更具可读性，因为你只是习惯于跳过'var'关键字。当您真的不关心具体类型是什么时，您不需要一直向下滚动来弄清楚代码在做什么。如果我真的需要知道下面的“item”是什么类型，我只需将鼠标悬停在它上面，Visual Studio就会告诉我。换句话说，我更愿意读书

foreach( var item in list ) { DoWork( item ); }

一遍又一遍地

foreach( KeyValuePair<string, double> entry in list ) { DoWork( Item ); }

当我试图消化代码时。我认为这在某种程度上可以归结为个人喜好。在这一点上，我将依赖常识——在重要的方面(安全性、数据库使用、日志记录等)保留强制标准。

-工业。

我们采用了“为人编写代码，而不是为机器编写代码”的理念，基于这样的假设:在维护模式中花费的时间要比在新的开发模式中花费的时间长好几倍。

对我来说，这就排除了编译器“知道”变量是什么类型的说法——当然，你不可能第一次就写出无效的代码，因为编译器会阻止你的代码编译，但是当下一个开发人员在6个月的时间里阅读代码时，他们需要能够推断出变量做得正确或不正确的地方，并快速确定问题的原因。

因此,

var something = SomeMethod();

在我们的编码标准中是不合法的，但在我们的团队中鼓励这样做，因为它增加了可读性:

var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
   DoWork( item ); 
}

来自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的反感说明了。net中双语的重要性。对于那些使用过VB . net的c#程序员来说，var的优势是显而易见的。标准的c#声明:

List<string> whatever = new List<string>();

在VB .NET中，相当于键入:

Dim whatever As List(Of String) = New List(Of String)

不过，在VB . net中没有人这样做。这样做是愚蠢的，因为从。net的第一个版本开始，你就可以这样做了…

Dim whatever As New List(Of String)

.．.它创建变量并在一个相当紧凑的行中初始化它。啊，但是如果你想要一个IList<string>，而不是一个List<string>?在VB .NET中，这意味着你必须这样做:

Dim whatever As IList(Of String) = New List(Of String)

就像你在c#中必须做的那样，显然不能使用var:

IList<string> whatever = new List<string>();

如果您需要不同的类型，它可以是。但优秀编程的基本原则之一是减少冗余，这正是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 i = 5;
int j = 5;

SomeType someType = new SomeType();
var someType = new SomeType();

.．.完全是主观的。

隐式类型意味着使用var关键字声明任何变量都不会在运行时造成损失，因此归根结底，这是一个关于如何让开发人员满意的争论。

摘自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，因为它违背了c#的根- C/ c++ /Java。尽管这是一个编译器技巧，但它使语言感觉不那么强类型。也许20多年的C语言已经在我们(反变量的人)的头脑中根深蒂固了，我们应该在等号的左右两边都有类型。

话虽如此，我可以看到它对于长泛型集合定义和长类名(如codinghorror.com示例)的优点，但在其他地方，如string/int/bool，我真的看不出这一点。特别是

foreach (var s in stringArray)
{

}

节省3个字符!

对我来说，主要的烦恼是无法看到var代表方法调用的类型，除非你将鼠标悬停在方法上或F12它。

当你将鼠标悬停在“var”上时，VS2008 w/resharper 4.1在工具提示中有正确的输入，所以我认为当你寻找一个类的所有用法时，它应该能够找到这个。

虽然还没有测试它是否这样做。

这次讨论有点晚了，但我想补充一点想法。

对于所有反对类型推断的人(因为这就是我们在这里真正谈论的内容)，lambda表达式呢?如果坚持始终显式地声明类型(匿名类型除外)，那么如何使用lambdas呢?“不要让我使用鼠标悬停”参数如何适用于var而不是lambdas?

更新

我刚刚想到了一个反对“var”的论点，我认为没有人提到过，那就是它“破坏”了“找到所有引用”，这可能意味着(例如)如果你在重构之前检查一个类的使用情况，你会错过类通过var使用的所有地方。

取决于，它使代码看起来“更干净”，但同意它使它更难以读…

我想这取决于你的看法。我个人从来没有因为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很有用。例如，我昨天需要一个类似于此的数据结构。您喜欢哪种表示法?

Dictionary<string, Dictionary<string, List<MyNewType>>> collection = new Dictionary<string, Dictionary<string, List<MyNewType>>>();

or

var collection = new Dictionary<string, Dictionary<string, List<MyNewType>>>();

请注意，在本例中使用var几乎不会引起歧义。然而，有时候这并不是一个好主意。例如，如果我像下面这样使用var，

var value= 5;

当我可以只写真正的类型，并消除任何歧义5应该如何表示。

double value = 5;

它当然可以让事情变得更简单，从我昨天写的代码来看:

var content  = new Queue<Pair<Regex, Func<string, bool>>>();
...
foreach (var entry in content) { ... }

如果没有var，这将是非常冗长的。

附录:花点时间学习具有真正类型推断的语言(例如f#)，就会发现编译器在正确获取表达式类型方面是多么出色。这当然意味着我倾向于尽可能多地使用var，现在使用显式类型表明变量不是初始化表达式的类型。

在测试过程中，我发现自己的代码是这样的:

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
Console.WriteLine(something);

现在，有时，我想看看SomeOtherThing本身包含什么，SomeOtherThing不是CallMethod()返回的相同类型。因为我使用了var，我只是改变了这个:

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();

:

var something = myObject.SomeProperty.SomeOtherThing;

如果没有var，我也必须不断改变左边声明的类型。我知道这是小事，但它非常方便。

我不认为var per say是一个可怕的语言特性，因为我每天都在Jeff Yates描述的代码中使用它。实际上，我几乎每次使用var都是因为泛型会导致一些极其冗长的代码。我活在冗长的代码中，但是泛型太过分了。

也就是说，我(显然……)认为var被滥用的时机已经成熟。如果在一个方法中，代码超过20行，并且到处都是vars，那么维护很快就会变成一场噩梦。此外，在教程中使用var是违背直觉的，在我的书中是一个大禁忌。

另一方面，var是一个“简单”的特性，新程序员会抓住并喜欢它。然后，在几分钟/几小时/几天内，当他们开始触及极限时，遇到了巨大的障碍。为什么我不能从函数中返回var这类问题。此外，向强类型语言添加伪动态类型很容易让新开发人员感到困惑。从长远来看，我认为var关键字实际上会让新程序员更难学习c#。

也就是说，作为一个有经验的程序员，我确实使用var，主要是在处理泛型(显然是匿名类型)时。我相信var将会是c#中最被滥用的特性之一。

在边缘情况下肯定会有分歧，但我可以告诉你我的个人指导方针。

当我决定使用var时，我看看这些标准:

变量的类型(对人来说)从上下文是很明显的 变量的确切类型(对人类来说)并不是特别相关。 [例如，你可以弄清楚算法在做什么，而不用关心你使用的是哪种容器] 类型名非常长，会影响代码的可读性(提示:通常是泛型)

相反，这些情况会促使我不使用var:

类型名称相对较短且易于阅读(提示:通常不是泛型) 从初始化式的名称来看，类型并不明显 确切的类型对于理解代码/算法非常重要 在类层次结构上，当一个人不能很容易地知道正在使用层次结构的哪个级别时

最后，我永远不会使用var的本机值类型或相应的可空<>类型(int，十进制，字符串，十进制?,……)。这里有一个隐含的假设，如果你使用var，一定有一个“原因”。

这些都是指导方针。你还应该考虑你同事的经验和技能，算法的复杂性，变量的寿命/范围，等等。

大多数时候，没有完美的正确答案。或者，这并不重要。

[编辑:删除重复的子弹]

来自Essential LINQ:

除非绝对必要，否则最好不要显式声明范围变量的类型。例如，下面的代码编译干净，但是编译器可以在没有正式声明的情况下推断出类型:

List<string> list = new List<string> { "LINQ", "query", "adventure" };
var query = from string word in list
      where word.Contains("r")
      orderby word ascending
      select word;

显式声明range变量的类型会强制对LINQ Cast操作符进行幕后调用。此调用可能会产生意想不到的结果，并可能会损害性能。如果您在LINQ查询中遇到性能问题，像这里所示的强制转换可能是开始寻找罪魁祸首的一个地方。(此规则的一个例外是当您使用非泛型Enumerable时，在这种情况下您应该使用强制转换。)

没有，只是不需要写两次类型名。http://msdn.microsoft.com/en-us/library/bb383973.aspx

这纯粹是为了方便。编译器将推断类型(基于右边表达式的类型)。

在大多数情况下，只是输入它更简单——想象一下

var sb = new StringBuilder();

而不是:

StringBuilder sb = new StringBuilder();

有时它是必需的，例如:匿名类型，比如。

var stuff = new { Name = "Me", Age = 20 };

我个人喜欢使用它，尽管它会降低代码的可读性和可维护性。

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

你最可能需要它的时候是匿名类型(100%需要);但它也避免了琐碎案件的重复，IMO使界限更加清晰。对于简单的初始化，我不需要看到类型两次。

例如:

Dictionary<string, List<SomeComplexType<int>>> data = new Dictionary<string, List<SomeComplexType<int>>>();

(请不要编辑上面的hscroll -它有点证明了这一点!!)

vs:

var data = new Dictionary<string, List<SomeComplexType<int>>>();

然而，在某些情况下，这是一种误导，并可能导致错误。如果原始变量和初始化类型不相同，请谨慎使用var。例如:

static void DoSomething(IFoo foo) {Console.WriteLine("working happily") }
static void DoSomething(Foo foo) {Console.WriteLine("formatting hard disk...");}

// this working code...
IFoo oldCode = new Foo();
DoSomething(oldCode);
// ...is **very** different to this code
var newCode = new Foo();
DoSomething(newCode);

使用var而不是显式类型使重构更容易(因此我必须反驳前面的帖子，他们的意思是它没有区别，或者它纯粹是“语法糖”)。

您可以更改方法的返回类型，而无需更改调用此方法的每个文件。想象一下

...
List<MyClass> SomeMethod() { ... }
...

就像这样

...
IList<MyClass> list = obj.SomeMethod();
foreach (MyClass c in list)
  System.Console.WriteLine(c.ToString());
...

如果您希望重构SomeMethod()以返回IEnumerable<MySecondClass>，则必须在使用该方法的每个地方更改变量声明(也在foreach中)。

如果你写

...
var list = obj.SomeMethod();
foreach (var element in list)
  System.Console.WriteLine(element.ToString());
...

相反，你不需要改变它。

您可以让编译器(以及接下来维护代码的人员)从初始化式赋值的右边推断类型。如果这种推断是可能的，编译器可以这样做，从而节省了您的一些输入。

如果这个推断对那个可怜的家伙来说很容易，那么你没有伤害到任何东西。如果推断很难，那么作为一般规则，您已经使代码更难维护 我不会这么做的。

Lastly, if you intended the type to be something particular, and your initializer expression actually has a different type, using var means it will be harder for you to find the induced bug. By explicitly telling the compiler what you intend the type to be, when the type isn't that, you would get an immediate diagnostic. By sluffing on the type declaration and using "var", you won't get an error on the initialization; instead, you'll get a type error in some expression that uses the identifier assigned by the var expression, and it will be harder to understand why.

寓意是，要谨慎使用var;您通常不会给您自己或您的下游维护人员带来很多好处。并希望他的理由是一样的，这样你就不会因为他认为使用var很容易而猜测他的意图。在编写一个具有较长生命周期的系统时，优化输入量是一个错误。

有时编译器也能比开发人员“更好”地推断出需要什么——至少开发人员不了解他所使用的api需要什么。

例如-当使用linq时:

示例1

Func<Person, bool> predicate = (i) => i.Id < 10;
IEnumerable<Person> result = table.Where(predicate);

示例2

var predicate = (Person i) => i.Id < 10;
var result = table.Where(predicate);

在上面的代码中-假设一个是使用Linq到Nhibernate或Linq到SQL，示例1将 返回Person对象的整个结果集，然后在客户端进行筛选。 然而，示例2将在服务器上执行查询(例如在Sql server上使用Sql)，因为编译器足够聪明，可以计算出Where函数应该采用表达式>而不是Func。

示例1中的结果在返回IEnumerable时也不能在服务器上进一步查询，而在示例2中，编译器可以计算出结果是否应该是IQueryable而不是IEnumerable

我曾经认为var关键字是一个伟大的发明，但我把一个限制，这是

只在类型很明显的情况下使用var(不要滚动或查看返回类型)

我意识到这并没有给我带来任何好处，并从我的代码中删除了所有的var关键字(除非他们是特别需要的)，现在我认为他们使代码可读性更差，特别是对其他人阅读你的代码。

它隐藏了意图，并且在至少一个实例中，由于类型的假设而导致某些代码的运行时错误。

从关于这一主题的讨论来看，结果似乎是:

Good: var customers = new List<Customer>();

争议性:var customers = dataAccess.GetCustomers();

忽略“var”神奇地帮助重构的错误观点，对我来说最大的问题是人们坚持认为他们不关心返回类型是什么，“只要他们能枚举集合”。

考虑:

IList<Customer> customers = dataAccess.GetCustomers();

var dummyCustomer = new Customer();
customers.Add(dummyCustomer);

现在考虑:

var customers = dataAccess.GetCustomers();

var dummyCustomer = new Customer();
customers.Add(dummyCustomer);

现在，重构数据访问类，使GetCustomers返回IEnumerable<Customer>，看看会发生什么……

这里的问题是，在第一个示例中，您明确了对GetCustomers方法的期望—您说您希望它返回一些行为类似于列表的东西。在第二个示例中，这个期望是隐式的，从代码中不能立即看出。

(对我来说)有趣的是，许多支持var的论点说“我不在乎它返回什么类型”，但接着说“我只需要迭代它……”。(因此它需要实现IEnumerable接口，这意味着类型很重要)。

对于那些认为var可以节省时间的狂热爱好者来说，它可以减少敲击键盘的次数:

StringBuilder sb = new StringBuilder();

than

var sb = new StringBuilder();

如果你不相信，你可以数数……

19对21

如果有必要我会解释的，但你试试吧……(取决于你的智能感知的当前状态，你可能需要为每一个输入更多)

你能想到的每一种类型都是如此!!

我个人的感觉是，除非在不知道类型的情况下，否则永远不应该使用var，因为它降低了代码中的识别可读性。大脑识别字体的时间比识别一整行字体要长。那些懂机器码和比特的老家伙知道我在说什么。大脑是并行处理的，当你使用var时，你强迫它序列化它的输入。为什么会有人想让自己的大脑更努力地工作呢?这就是电脑的作用。

令人惊讶的是，到目前为止还没有注意到这一点，但对foreach循环变量使用var是常识。

如果您指定了特定的类型，则可能会有编译器无声地将运行时强制转换插入程序的风险!

foreach (Derived d in listOfBase)
{

上面的代码将被编译。但是编译器会插入一个从Base到Derived的向下转换。因此，如果列表中的任何内容在运行时不是派生的，则存在无效的强制转换异常。类型安全受到损害。隐形演员太可怕了。

排除这种情况的唯一方法是使用var，因此编译器会根据列表的静态类型来确定循环变量的类型。

Var一点也不像变量。变量仍然是强类型的，只是你不需要按下键来得到它。您可以在Visual Studio中将鼠标悬停在它上以查看类型。如果您正在阅读打印的代码，则可能需要稍微考虑一下以确定类型是什么。但是只有一行声明了它，而有很多行使用它，所以给东西起个像样的名字仍然是让你的代码更容易理解的最好方法。

使用智能感知是懒惰吗?这比输入整个名字还少。或者有些事情不那么费力，但不值得批评?我认为有，var就是其中之一。

因冗余原因删除。

var仍然被初始化为正确的变量类型——编译器只是从上下文推断它。正如您所提到的，var使我们能够存储对匿名类实例的引用——但它也使更改代码变得更容易。例如:

// If you change ItemLibrary to use int, you need to update this call
byte totalItemCount = ItemLibrary.GetItemCount();

// If GetItemCount changes, I don't have to update this statement.
var totalItemCount = ItemLibrary.GetItemCount();

是的，如果很难从变量的名称和用法中确定变量的类型，那么无论如何都要显式声明它的类型。

这并不坏，这更多的是一种风格上的东西，往往是主观的。当你使用var或不使用var时，它会增加不一致性。

另一个值得关注的情况是，在下面的调用中，你不能仅通过查看CallMe返回的代码来判断类型:

var variable = CallMe();

这是我对var的主要抱怨。

当我在方法中声明匿名委托时，我使用var，在某种程度上var看起来比我使用Func更干净。考虑下面的代码:

var callback = new Func<IntPtr, bool>(delegate(IntPtr hWnd) {
   ...
});

编辑:根据Julian的输入更新最后一个代码样例

这两种说法都不是绝对正确的;Var对可读性既有正面影响，也有负面影响。在我看来，var应该在以下情况之一成立时使用:

类型是匿名的(好吧，这里没有任何选择，因为在这种情况下它必须是var) 根据指定的表达式，类型是明显的(即var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

Var没有性能影响，因为它是语法糖;一旦编译成IL，编译器就会推断出类型并定义它;没有什么动态的东西。

在我看来，大量使用var是没有问题的。它本身不是一个类型(您仍然在使用静态类型)。相反，这只是一个节省时间的方法，让编译器自己判断要做什么。

像任何其他节省时间的方法(例如自动属性)一样，在到处使用它之前，最好先了解它是什么以及它是如何工作的。

我认为你可能误解了c#中var的用法。它仍然是强类型，不像VB的变体类型，所以使用或不使用它对性能没有影响。

因为它对最终编译的代码没有影响，所以它实际上是一个设计器的选择。就我个人而言，我不使用它，因为我发现定义了完整类型的代码更容易阅读，但我可以想象，几年后，完整类型声明将像现在的匈牙利符号一样被看待——额外的类型与默认情况下智能感知提供给我们的信息相比并没有真正的好处。

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.

Var还不错。记住这一点。Var还不错。重复一遍。Var还不错。记住这一点。Var还不错。重复一遍。

如果编译器足够聪明，可以从上下文中找出类型，那么您也可以。你不需要在申报时把它写下来。而智能感知让这变得更加不必要。

Var还不错。记住这一点。Var还不错。重复一遍。Var还不错。记住这一点。Var还不错。重复一遍。

如果有人使用var关键字是因为他们不想“找出类型”，那肯定是错误的原因。var关键字不会创建动态类型的变量，编译器仍然需要知道该类型。由于变量总是具有特定的类型，因此如果可能的话，该类型在代码中也应该是明显的。

使用var关键字的理由如下:

在需要的地方，即声明匿名类型的引用。 它使代码更具可读性，即删除重复的声明。

写出数据类型通常会使代码更容易理解。它显示了您正在使用的数据类型，因此您不必通过先弄清楚代码的功能来弄清楚数据类型。

第一。

Var不是一个类型，也不是什么特殊的特性(比如c# 4.0的动态特性)。它只是一个语法糖。你要求编译器通过右边的表达式来推断类型。唯一需要的地方是匿名类型。

我不认为使用var既好又坏，这是一种编码风格。我个人不使用它，但我不介意其他团队成员使用它。

我想你在你的问题中指出了var的主要问题:“我不需要弄清楚类型”。正如其他人指出的那样，var是有一席之地的，但如果你不知道你正在处理的类型，你很有可能会遇到问题——不是在所有情况下，但那里有足够的气味，所以你应该怀疑。

好吧，这个问题会一直固执己见，但我会试着给出我的观点-尽管我认为我的观点是如此混乱，你可能不会从中得到什么。

首先——有匿名类型，为此你需要使用“var”关键字来分配一个匿名类型作为类的对象——这里没有太多的讨论，“var”是必要的。

然而，对于更简单的类型，如int型、长型、字符串型等等，我倾向于输入适当的类型。主要是因为它有点像“懒人的工具”，我在这里看不到太多的好处，很少的按键和它可能带来的困惑，这是不值得的。特别是浮点数的各种类型(浮点数、双精度数、十进制数)使我感到困惑，因为我对字面量中的后缀不坚定——我喜欢在源代码中看到类型。

话虽如此，如果类型更复杂和/或它显式地重复在赋值的右侧，我倾向于大量使用var。这可以是一个List<string>或etc，例如:

var list = new List<string>();

在这种情况下，我认为没有必要重复类型两次——特别是当您开始更改代码和类型更改时——泛型类型可能会变得越来越复杂，因此必须更改它们两次只是一种痛苦。当然，如果你希望针对IList<string>编码，那么你必须显式地命名类型。

简而言之，我做了以下事情:

当类型很短或不能脱离上下文读取时，显式地命名类型 在必要时使用var(废话) 当var(在我看来)不影响可读性时，使用它来偷懒

当然，int很简单，但当变量的类型是IEnumerable<MyStupidLongNamedGenericClass<int, string>>时，var会让事情变得更简单。

我只在清楚地看到使用的类型时使用var。

例如，在这种情况下，我会使用var，因为你可以立即看到x将是“MyClass”类型:

var x = new MyClass();

我不会在这种情况下使用var，因为你必须将鼠标拖动到代码上，并查看工具提示来查看MyFunction返回的类型:

var x = MyClass.MyFunction();

特别是，在右边甚至不是一个方法，而只是一个值的情况下，我从不使用var:

var x = 5;

(因为编译器不知道我想要一个字节，短，int或其他)

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')时，我们阻止了对使用这种语法定义的变量的赋值。

埃里克的回答是……

c#中泛型类型的命名空间作用域别名

是相关的。

部分问题在于c#中没有强类型的混叠。因此许多开发人员使用var作为部分代理。

不要这样做，这会让你的代码难以阅读。

总是使用尽可能严格的输入，拐杖只会让你的生活地狱。

这没有错，但可能不合适。参见所有其他回答的例子。

Var x = 5;(坏的)

var x = new SuperDooperClass();(好)

Var x = from t，单位为db。select new {Property1 = t.Field12};(更好的)

“关于我的品味，你唯一能说的就是它过时了，假以时日，你也会过时的。”托尔金。

var是c# 3.0和LINQ中为匿名类型引入的占位符。

因此，它允许在一个集合中为更少的列编写LINQ查询。不需要在内存中复制信息，只加载完成你需要做的事情所必需的东西。

var的使用一点也不坏，因为它实际上不是一个类型，但正如在其他地方提到的，它是一个类型的占位符，它是并且必须定义在等式的右边。然后，编译器将用类型本身替换关键字。

即使使用智能感知，当一个类型的名称很长时，它也特别有用。只需要写var，然后实例化它。之后阅读您的代码的其他程序员将很容易理解您在做什么。

就像使用

public object SomeObject { get; set; }

而不是:

public object SomeObject {
    get {
        return _someObject;
    } 
    set {
        _someObject = value;
    }
}
private object _someObject;

每个人都知道属性在做什么，就像每个人都知道var关键字在做什么一样，这两个例子都倾向于通过简化它来简化可读性，并使程序员更容易编写有效的代码。

var很好，因为它遵循经典的DRY规则，当在声明变量的同一行中指出类型时，它特别优雅。(例如var city = new city ())

如果你知道类型，就使用类型。 如果你不知道哪种类型，为什么不呢? 如果您不知道类型，也没关系——您已经找到了唯一有效的用法。

我很抱歉，但如果你能做到的最好的是“它使代码全部对齐”，那不是一个好答案。找一种不同的方式来格式化代码。

为什么var不应该仅仅被用作“输入快捷方式”，而应该被用于它们主要设计的场景:Resharper(至少v4.5)如果一个类型被表示为var，就无法找到它的用法。这在重构或分析源代码时可能是一个真正的问题。

如果你很懒，对匿名类型以外的任何类型都使用var，你应该被要求在这些变量的命名中使用匈牙利符号。

var iCounter=0;

生命!

天啊，我真想念VB。

大多数人忽视的是:

var something = new StringBuilder(); 

通常打字的速度没有

StringBuilder something = KEY'TAB'();

对于LINQ，使用var的另一个很好的理由是编译器可以更优化查询。

如果你使用一个静态列表来存储结果，它将在你分配给列表的地方执行，但是使用var，它可以潜在地将原始查询与代码中后面的查询合并，从而对数据库进行更优化的查询。

我有一个例子，我在第一个查询中提取了一些数据，然后循环遍历并请求更多数据以打印出一个表。

LINQ合并了这些，所以第一个只提取id。

然后在循环中，它添加了一个我没有在那里做的额外连接来获取我包含在原始数据中的数据。

经过测试，这种方法效率更高。

如果我们没有使用var，它就会像我们写的那样进行查询。

在做了十年的Java专业人员之后，我在c#世界里还是个新手。我最初的想法是“哦，不!这就把类型安全丢进了下水道”。然而，我对var了解得越多，我就越喜欢它。

1) Var与显式声明的类型一样是类型安全的。这都是关于编译时语法糖。

2)遵循DRY原则(不要重复)。DRY是关于避免冗余的，在两边都命名类型肯定是冗余的。避免冗余就是要让你的代码更容易修改。

3)至于确切的型号……嗯. .我认为你应该有一个大致的概念你有一个整数，一个套接字，一些UI控件，等等。智能感知将从这里引导你。知道确切的类型通常并不重要。例:我认为99%的情况下你并不关心给定的变量是long还是int, float还是double。对于最后1%的情况，在真正重要的地方，只需将鼠标指针悬停在var关键字上方。

4)我曾看到过这样一种荒谬的观点:现在我们需要回到1980年风格的匈牙利疣，才能区分变量类型。毕竟，在蒂莫西·道尔顿(Timothy Dalton)扮演詹姆斯·邦德(James Bond)的时代，这是判断变量类型的唯一方法。但现在是2010年。我们已经学会了根据变量的用法和内容来命名变量，并让IDE指导我们确定它们的类型。只要继续这样做，var就不会伤害你。

总而言之，var不是什么大东西，但它确实是一个很好的东西，而且它是Java最好很快复制的东西。所有反对的观点似乎都是基于ide之前的谬误。我会毫不犹豫地使用它，我很高兴R#帮助我做到这一点。

var是处理匿名类型的方法，无论是否来自LINQ语句。任何其他用途在很大程度上取决于谁将阅读您的代码以及有哪些指导方针。

如果你是唯一的观众，或者你的观众对使用var很熟悉，或者非常熟悉你的代码，那么我想这没有关系。如果你像这样使用:var s = new SqlConnection()，那么这在很大程度上无关紧要，可能会提高代码的可读性。如果人们不太挑剔，他们可以做一些工作来了解不明显的类型(这在大多数情况下是不需要的，你在下面的语句中如何使用它通常会解释一切)，那么它是好的。

但是如果你有挑剔的，思想封闭的队友，他们喜欢抱怨，或者如果你公司的设计准则特别禁止在类型不明显时使用var，那么你很可能会遇到强烈的反对。

如果使用var会让你的代码难以阅读，你可能会因为使用var而受到伤害，即使这可能是你的应用程序设计的问题。

如果var引入了歧义(有点像你的IEnumerable/IEnumerable例子)，不要使用它，而是显式地使用它。但var确实有它的便利，在某些情况下，恕我直言，它甚至可以通过减少混乱来提高可读性。

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关键字将解析为该类型名称，并且不会被视为隐式类型局部变量声明的一部分。