var关键字是否应该普遍使用？

Question

RT，我现在在做的这个系统中存在大量用var代替具体类名定义的变量，并且这是team leader推荐的做法，理由是var关键字拼写简单，可以节省编码时间。但是我觉得，大量以var定义的变量，肉眼不能一目了然的看出变量类型，总是得看一下上下文，在修改和调试的时候带来不少困扰，而且在IDE环境下类名都是有智能提示的，拼写类名应该不会占用太多时间，这样做感觉有点得不偿失啊。大伙儿觉得呢？

Answer 1

我平时基本不用var
好像在foreach中偶尔用了一下

Answer 2

眼睛向var右边漂移一点点，你可以更加清楚地看到实例化对象的类型。编程中变量是什么类型，我是比较倾向于测试驱动，既不是靠死记硬背，而是靠前后一贯的灵性。换句话说，只有编译器报告你出错时，或者测试程序报告你出错时，你才应该不断反复读自己的代码。否则，你应该多多考虑自己的是如何测试代码的，而不是反复欣赏自己的代码。代码并不重要，测试才重要。

Answer 3

关于设计var的原因，也许msdn说明了一点点。可以参考 http://msdn.microsoft.com/zh-cn/library/bb384061.aspx客观上说，并没有出现lz你所说的“在修改和调试的时候带来不少困扰”，而是可以明显感觉到提高了开发速度的。如果你得到了相反的结论，你可以每一次都花时间去决定该在前边些什么类型申明。不过我想你的“修改和调试”的手段可能不太精通，这也许不能怪var这个语法。

Answer 4

过度使用var会使得源代码晦涩难懂，我只说是过度使用。在必要的时候，才推荐使用var，比如当变量用来存储一个匿名类型或者匿名类型集合等。使用var定义变量时有以下四个特点（网上资料）： 　
　1. 必须在定义时初始化。
2. 一但初始化完成，就不能再给变量赋与初始化值类型不同的值了。 　　
3. var要求是局部变量。 　　
4. 使用var定义变量和object不同，它在效率上和使用强类型方式定义变量完全一样。

Answer 5

我也是偶尔在foreach中用一下。大篇幅使用var 会降低代码可读性。

Answer 6

我感觉这四条真是废话啊只要记住var是简写的，C#是强类型的1.不初始化能确定类型吗？不确定类型编译器咋编译？2.这个必须的，编译器也不干啊3.成员变量弄个var a;谁知道a是什么类型4.他就是强类型

Answer 7

我觉得一般情况还是不要用var只是在用Linq的时候返回类型的名字实在太复杂，才有必要用var

Answer 8

TDD么，我前段时间接触了不少有关敏捷开发的书籍和文章，受敏捷价值观影响，我也认为测试驱动是一项很好的实践，非常愿意尝试，但之前没有实践过，在如何上手方面有点不得要领。
指望在公司项目里实践看来是不太现实了，这个系统自动化测试都不太有，几乎完全是人工测试，之前转正谈话的时候（我是今年毕业的，现在的公司是毕业前就进入实习的），我提出是否考虑建立较完善的测试体系，leader表示这是一直以来想做的事，但现阶段没有精力去做。

Answer 9

看到var就烦，从来不用var，维护时浪费精力与时间，还要求有很强的记忆能力。

Answer 10

楼主,是这样的,基于不同的生产手段,关注的焦点会有所不同,
可能会是很大的差别,在一些拥有自动化测试手段的开发组织.
一个被提交的工单,是以自动化测试标定为合格,
一旦通过测试,不会有人再去看这些代码,
如果以后这个组件被证明存在缺陷,那也和最初提交工单的程序员没有任何关系了,
设计师会重构出新的设计文档接口,安排新的测试实现和代码实现在另一种更加自动化的方式下,甚至都不需要提交代码,而是通过更加专业的开发工具提交文档,
文档通过测试标定工单合格,那样的话根本就不接触代码然而,还有很多开发组织,他们需要手工编写大量的代码,
并且经常需要修改这些代码,
所以代码的可维护性就显得尤其重要,
为此会制定一些书写建议和规范,基于我们的生产手段,我不在乎代码中是否使用var

Answer 11

看来大家观点都跟我一致啊
我认为var是配合匿名类用的，因为它没有类名啊，只能用var，其他时候var就是个语法糖，看起来可以用来定义一切变量，但实际上是由编译器进行类型推断的，只不过是把写完整类名的事情交给编译器了，所以要在定义的时候初始化，不然怎么推断类型，楼上也说了C#是强类型的，变量必须有类型的。一次leader看我敲代码，我都是写完整类名的，leader说，用var多好啊，打起来省事，在这种细节方面省下一点时间，累积起来就比较多了。我表示本人菜鸟一只，leader这么说，我以为经验之谈，但后来看到系统里大片var定义的变量，感觉挺别扭的，于是来看看大伙儿怎么说。

Answer 12

很成熟的开发体系啊我们公司推的产品有很好的理念，市场前瞻性也不错
但是开发过程很让人崩溃啊，
没有需求文档、没有设计文档、代码几乎没有注释、没有测试文档、没有自动化测试
测试几乎完全依赖人工，经常发生回归现象
我想跟Boss提提意见（整个氛围比较轻松，直接跟Boss对话是比较容易的），改善下开发流程
但考虑到我所有关于开发流程的知识都是看来的，没有实践过，不太有说服力
而且这等于是说leader的管理有问题，恐日后尴尬
最近正为这事儿苦恼啊

Answer 13

我个人习惯用var，重构代码时类名修改了也只修改右边。不是很好么。这东西就是个习惯问题(向右看齐)。能省则省。

Answer 14

不使用var，
不使用linq
不使用ORM
不盲目分层，让所谓的3层去死软件可以分层，但绝不仅仅是多少层得问题，而是分层的思想是什么，最重要的是为什么要这样做？然后是怎么分层合适，什么逻辑层和UI分层，大多数人都是在盲从和误解，就像大众始终是盲目的一样，我只是想说要思考为什么要这么做，如果按照界面和逻辑分离的思想，自从vs2003之后微软就已经把程序分层了，因为以前的界面代码和窗体的.cs文件时在一起的，后来就分开了，这就是分层，不知从何时起有人有单独把逻辑处理从cs文件中剥离出来又单独作为一个dll，美其名曰可以直接替换BLL层，这样和直接替换exe有多少区别？ORM的时代还没到来：
ORM的思想很好，但是搞清楚，现在用的数据库是关系型数据库，不是对象型数据库，多余的转换，多余的代码，每次看到别人写的实体就想吐，操作个数据库直接执行sql就好了，用的着兜一圈吗，还要把数据库表转换为对象，其实ORM和linq另外一个好的思想是统一开发接口，比如多种数据源，但是实际上并非如此，软件往往只用到一个数据库，如果要用多数据库，用DoNet的接口写一个数据转换类就可以了，什么CSLA.NET,Hibernate之类的全是浮云，只能增大无用代码的输入量和开发时间，同时降低程序效率

Answer 15

真正的ORM时代随时来临，应该做好准备。

Answer 16

加群 12890082 java asp.net

Answer 17

var 的优点在于不用关心类型，但是。。如果代码风格不佳，混合着很多难看的代码。var 将是另外一个地狱。

Answer 18

var 很好用啊，我喜欢，var并不是定义一个变量的作用

Answer 19

List<Customer> customers = new List<Customer>();例1：
var c1 = from c in customers
         select new { CustomerId = c.Id, CustomerName = c.Name };var test = new { Id = 1, Name = 2 };Console.WriteLine(test.Id);例2：
IEnumerable<Customer> c2 = from c in customers
                           select c;例1用var是恰当的， 例2 var跟指定类型一致。

Answer 20

这个问题CLR via C#中解释得很好啊，什么时候用合适