Question

可能重复：
C# 'var' keyword versus explicitly defined variables

编辑：

对于仍在观看此事的人，我完全改变了对var的看法。我认为这主要是由于我对这个主题的回应。我现在是一个狂热的'var'用户，我认为它的支持者评论在几乎所有情况下都是绝对正确的。我认为我最喜欢var的是它真的可以减少重复（符合DRY），并使你的代码更加清晰。它支持重构（当你需要更改某些东西的返回类型时，你需要更少的代码清理来处理，并且不，不是每个人都有一个花哨的重构工具！），并且有趣的是，人们似乎并没有真正的问题不知道前面变量的具体类型（它很容易“发现”按需类型的功能，这通常是必要的，即使你知道类型的名称。）

对于'var'关键字，这是一个热烈掌声 !!

这是一个相对简单的问题......更多的是民意调查。我是C＃的巨大粉丝，自从.NET首次发布之前已经使用了8年多。我喜欢对语言所做的所有改进，包括lambda表达式，扩展方法，LINQ和匿名类型。但是，C＃3.0中有一个功能我觉得被SORELY误用了......'var'关键字。

自从C＃3.0发布以来，在博客，论坛和是，甚至Stackoverflow上，我已经看到var替换了几乎所有已编写的变量！对我来说，这是对该功能的严重滥用，并导致非常随意的代码，由于缺乏变量实际上是什么类型的清晰度，可能会有许多混淆的错误。

'var'只有一个真正有效的用途（至少在我看来）。你问，这有效用途是什么？唯一有效的用途是当您无法知道类型时，以及唯一可能发生这种情况的实例：

访问匿名类型

时

匿名类型没有编译时标识，因此var是唯一的选项。这是添加var的唯一原因......支持匿名类型。

所以...你的意见是什么？鉴于var在博客，论坛上的大量使用，由ReSharper等工具建议/强制执行，许多即将到来的开发人员会认为它是一个完全有效的东西。

你认为var应该如此丰富地使用吗？
您认为var应该用于除匿名类型以外的任何其他内容吗？
在发布到博客的代码中使用是否可以保持简洁......简洁？（我自己也不确定这个答案......也许是免责声明）
作为一个社区，我们是否应该鼓励更好地使用强类型变量来提高代码清晰度，或者让C＃变得更模糊，更少描述？

我想了解社区的意见。我看到var使用了很多，但我很少知道为什么，并且有一个很好的理由（即简洁/简洁）。

Answer 1

var是一个很棒的主意，可以帮助实现良好编程的关键原则： DRY ，即不要重复自己。

VeryComplicatedType x = new VeryComplicatedType();

是错误的编码，因为它重复VeryComplicatedType，并且效果都是负面的：更冗长和样板代码，更少的可读性，对于读者和代码的编写者来说都是愚蠢的“makework”。因此，与Java和以前版本的C＃相比，我将var视为C＃3中非常有用的增强。

当然，通过使用RHS表达类型不明确且不明显的表达式（例如，对声明可能很远的方法的调用），它可能会被轻度误用 - 这种滥用可能会降低可读性（通过强制）读者寻找方法的声明或深入思考其他一些微妙的表达式类型而不是增加它。但如果你坚持使用var 避免重复，你就会处于最佳状态，而且不会被滥用。

Answer 2

我认为它应该用于那些类型明确指定在同一语句中的其他地方的情况：

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

阅读很痛苦。这可以由以下内容取代而不会失去清晰度：

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

Answer 3

流行测验！

这是什么类型：

var Foo = new string[]{"abc","123","yoda"};

这个怎么样：

var Bar = {"abc","123","yoda"};

我大致不再需要确定那些类型而不是类型的明确冗余规范。作为程序员，我没有让编译器找出对我来说很明显的事情的问题。你可能不同意。

干杯。

Answer 4

永远不要说永远。我很确定有很多问题让人们在var上阐述了他们的观点，但这里再次出现了我的观点。

var是一种工具;在适当的地方使用它，如果不适合则不要使用它。你是对的，var唯一需要使用的是匿名类型，在这种情况下你没有要使用的类型名称。就个人而言，我认为在可读性和懒惰方面必须考虑任何其他用途;特别是，当避免使用繁琐的类型名称时。

var i = 5;

（懒惰）

var list = new List<Customer>();

（便利）

var customers = GetCustomers();

（可疑;当且仅当GetCustomers（）返回IEnumerable时，我认为这是可以接受的）

Answer 5

阅读Haskell。它是一种静态类型语言，您很少需要说明任何类型。所以它使用与var相同的方法，作为标准的“惯用”编码风格。

如果编译器可以为你解决问题，为什么要写两次相同的东西？

我的一位同事起初非常反对var，就像你一样，但现在已经习惯性地使用它了。他担心这会使程序不那么自我记录，但实际上这种方法更多是由于过长的方法造成的。

Answer 6

var MyCustomers = from c in Customers 
                  where c.City="Madrid" 
                  select new { c.Company, c.Mail };

如果我只需要来自客户的公司和邮件集合。这是无意义的定义新类型与成员我需要的。

Answer 7

如果您认为两次提供相同的信息可以减少错误（许多网页表单的设计者坚持要求您输入两次电子邮件地址似乎同意），那么您可能会讨厌var。如果你编写了许多使用复杂类型规范的代码，那么它就是天赐之物。

编辑：稍微考虑一下（听起来好像我不赞成var）：

在英国（至少在我去的时候），标准做法是让计算机科学专业的学生学习如何使用标准ML进行编程。与其他函数式语言一样，它有一个类型系统，它使C + / Java模型中的语言变得羞耻。

无论如何，我当时注意到（并听到其他学生的类似评论）是因为编译器对类型有如此强烈的挑剔而导致编译是一个噩梦，但是一旦编译完成，它们就会几乎总是没有错误地运行。

SML（和其他函数式语言）的这个方面似乎是提问者认为是“好事”的一个方面 - 即任何有助于编译器在编译时捕获更多错误的东西都是好的。

现在这是SML的事情：它在分配时仅使用类型推断。所以我认为类型推断本身并不坏。

Answer 8

我同意其他人认为var消除了冗余。我决定使用var尽可能地消除冗余。我认为一致性很重要。选择一种风格并通过项目坚持下去。

Answer 9

正如Earwicker所指出的，有一些函数式语言，Haskell是一个，而F＃是另一个，其中这种类型推断被更普遍地使用--C＃类比将声明返回类型和方法的参数类型称为“var” ，然后让编译器为您推断静态类型。静态和显式输入是两个正交的问题。

事实上，使用“var”是动态类型是否正确？根据我的理解，这就是C＃4.0中新的“动态”关键字的用途。 “var”用于静态类型推断。如果我错了，请纠正我。

Answer 10

我必须承认，当我第一次看到var关键字弹出时，我非常怀疑。

然而，这绝对是缩短新声明行的一种简单方法，我会一直使用它。

但是当我更改底层方法的类型时，并使用var接受返回类型。我偶尔会遇到运行时错误。大多数仍然被编译器选中。

我遇到的棘手问题是当我不确定使用什么方法时（我只是通过自动完成查看）。如果我选择了错误的并且期望它是FOO类型并且它是BAR类型那么需要一段时间才能弄明白。

如果我在两种情况下都按字面指定了变量类型，那么它会节省一些挫折感。

总的来说，好处超过了问题。

Answer 11

我不得不反对var以任何有意义的方式减少冗余的观点。在这里提出的案例中，类型推断可以而且应该来自IDE，它可以更自由地应用，而不会损失可读性。

C＃中'var'的邪恶？

编辑：

11 个答案: