110,533
社区成员
发帖
与我相关
我的任务
分享var关键字是否应该普遍使用？
RT，我现在在做的这个系统中存在大量用var代替具体类名定义的变量，并且这是team leader推荐的做法，理由是var关键字拼写简单，可以节省编码时间。但是我觉得，大量以var定义的变量，肉眼不能一目了然的看出变量类型，总是得看一下上下文，在修改和调试的时候带来不少困扰，而且在IDE环境下类名都是有智能提示的，拼写类名应该不会占用太多时间，这样做感觉有点得不偿失啊。大伙儿觉得呢？
...全文
请发表友善的回复…
发表回复
sjg20010414 2011-09-27
- 打赏
- 举报
这个问题CLR via C#中解释得很好啊，什么时候用合适
dreammaster 2011-09-23
- 打赏
- 举报
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跟指定类型一致。
例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跟指定类型一致。
liujie1575720297 2011-09-23
- 打赏
- 举报
一般不用
hentlary 2011-09-22
- 打赏
- 举报
滥用就会有点麻烦
erictang2003 2011-09-22
- 打赏
- 举报
var 很好用啊，我喜欢，var并不是定义一个变量的作用
zh6335901 2011-09-21
- 打赏
- 举报
类型比较复杂且很容易看出类型的时候推荐用
fyjabb 2011-09-21
- 打赏
- 举报
加群 12890082 java asp.net
showjim 2011-09-21
- 打赏
- 举报
[Quote=引用 22 楼 sbwwkmyd 的回复:]
个人感觉这是很明显的资源浪费，代码是一次性的。如果程序简单还好，如果稍麻烦一点的逻辑代价就太高了。
[/Quote]
补充一点，自动测试与代码修改根本就不冲突，那只是业务流程而已。
个人感觉这是很明显的资源浪费，代码是一次性的。如果程序简单还好，如果稍麻烦一点的逻辑代价就太高了。
[/Quote]
补充一点，自动测试与代码修改根本就不冲突，那只是业务流程而已。
showjim 2011-09-21
- 打赏
- 举报
[Quote=引用 18 楼 athwind 的回复:]
ORM的时代还没到来：
ORM的思想很好，但是搞清楚，现在用的数据库是关系型数据库，不是对象型数据库，多余的转换，多余的代码，每次看到别人写的实体就想吐，操作个数据库直接执行sql就好了，用的着兜一圈吗，还要把数据库表转换为对象，其实ORM和linq另外一个好的思想是统一开发接口，比如多种数据源，但是实际上并非如此，软件往往只用到一个数据库，如果要用多数据库，用DoNet的接口写一个数据转换类就可以了，什么CSLA.NET,Hibernate之类的全是浮云，只能增大无用代码的输入量和开发时间，同时降低程序效率[/Quote]
真正的ORM时代随时来临，应该做好准备。
ORM的时代还没到来：
ORM的思想很好，但是搞清楚，现在用的数据库是关系型数据库，不是对象型数据库，多余的转换，多余的代码，每次看到别人写的实体就想吐，操作个数据库直接执行sql就好了，用的着兜一圈吗，还要把数据库表转换为对象，其实ORM和linq另外一个好的思想是统一开发接口，比如多种数据源，但是实际上并非如此，软件往往只用到一个数据库，如果要用多数据库，用DoNet的接口写一个数据转换类就可以了，什么CSLA.NET,Hibernate之类的全是浮云，只能增大无用代码的输入量和开发时间，同时降低程序效率[/Quote]
真正的ORM时代随时来临，应该做好准备。
showjim 2011-09-21
- 打赏
- 举报
[Quote=引用 11 楼 moneysoft 的回复:]
在一些拥有自动化测试手段的开发组织.
一个被提交的工单,是以自动化测试标定为合格,
一旦通过测试,不会有人再去看这些代码,
如果以后这个组件被证明存在缺陷,那也和最初提交工单的程序员没有任何关系了,
设计师会重构出新的设计文档接口,安排新的测试实现和代码实现
[/Quote]
个人感觉这是很明显的资源浪费，代码是一次性的。如果程序简单还好，如果稍麻烦一点的逻辑代价就太高了。
[Quote=引用 11 楼 moneysoft 的回复:]
在另一种更加自动化的方式下,甚至都不需要提交代码,而是通过更加专业的开发工具提交文档,
文档通过测试标定工单合格,那样的话根本就不接触代码[/Quote]
这只适用于工序与模型相对稳定的情况，这部分的后台代码维护的频率应该更高。
我相信现在这个时代，程序需要更多的是个性化，不是什么配置或生成工具能做的。
当然自动化还是需要的，这一部分都不应该是讨论的重点了。
[Quote=引用 11 楼 moneysoft 的回复:]
然而,还有很多开发组织,他们需要手工编写大量的代码,
并且经常需要修改这些代码,
所以代码的可维护性就显得尤其重要,
为此会制定一些书写建议和规范,[/Quote]
手工编写大量代码，这个并不能说明自动化程度不高，关键是手工编写的代码一般不应该具有重复的抽象逻辑。
[Quote=引用 11 楼 moneysoft 的回复:]
基于我们的生产手段,我不在乎代码中是否使用var
[/Quote]
只能说明你们的生产的产品需求是相对稳定的，主体是自动化，而且你们并不在意次要资源的浪费。
在一些拥有自动化测试手段的开发组织.
一个被提交的工单,是以自动化测试标定为合格,
一旦通过测试,不会有人再去看这些代码,
如果以后这个组件被证明存在缺陷,那也和最初提交工单的程序员没有任何关系了,
设计师会重构出新的设计文档接口,安排新的测试实现和代码实现
[/Quote]
个人感觉这是很明显的资源浪费，代码是一次性的。如果程序简单还好，如果稍麻烦一点的逻辑代价就太高了。
[Quote=引用 11 楼 moneysoft 的回复:]
在另一种更加自动化的方式下,甚至都不需要提交代码,而是通过更加专业的开发工具提交文档,
文档通过测试标定工单合格,那样的话根本就不接触代码[/Quote]
这只适用于工序与模型相对稳定的情况，这部分的后台代码维护的频率应该更高。
我相信现在这个时代，程序需要更多的是个性化，不是什么配置或生成工具能做的。
当然自动化还是需要的，这一部分都不应该是讨论的重点了。
[Quote=引用 11 楼 moneysoft 的回复:]
然而,还有很多开发组织,他们需要手工编写大量的代码,
并且经常需要修改这些代码,
所以代码的可维护性就显得尤其重要,
为此会制定一些书写建议和规范,[/Quote]
手工编写大量代码，这个并不能说明自动化程度不高，关键是手工编写的代码一般不应该具有重复的抽象逻辑。
[Quote=引用 11 楼 moneysoft 的回复:]
基于我们的生产手段,我不在乎代码中是否使用var
[/Quote]
只能说明你们的生产的产品需求是相对稳定的，主体是自动化，而且你们并不在意次要资源的浪费。
逐风 2011-09-21
- 打赏
- 举报
var 的优点在于不用关心类型，但是。。如果代码风格不佳，混合着很多难看的代码。var 将是另外一个地狱。
aoguanhai 2011-09-20
- 打赏
- 举报
var 挺乱的
游不出缸的鱼 2011-09-20
- 打赏
- 举报
[Quote=引用 14 楼 icedmilk 的回复:]
这是中国软件开发的现状
极度缺乏专业的项目管理人员，现在的管理人员都太操蛋
[/Quote]
感觉很多管理都是直接从技术NB的人里面提拔的，没有受过管理方面的培训，而如果他本人对管理技巧也不太关注的话，情况就会比较糟糕了
这是中国软件开发的现状
极度缺乏专业的项目管理人员，现在的管理人员都太操蛋
[/Quote]
感觉很多管理都是直接从技术NB的人里面提拔的，没有受过管理方面的培训，而如果他本人对管理技巧也不太关注的话，情况就会比较糟糕了
DSIOF3KIDSKTR 2011-09-20
- 打赏
- 举报
不使用var，
不使用linq
不使用ORM
不盲目分层，让所谓的3层去死
软件可以分层，但绝不仅仅是多少层得问题，而是分层的思想是什么，最重要的是为什么要这样做？然后是怎么分层合适，什么逻辑层和UI分层，大多数人都是在盲从和误解，就像大众始终是盲目的一样，我只是想说要思考为什么要这么做，如果按照界面和逻辑分离的思想，自从vs2003之后微软就已经把程序分层了，因为以前的界面代码和窗体的.cs文件时在一起的，后来就分开了，这就是分层，不知从何时起有人有单独把逻辑处理从cs文件中剥离出来又单独作为一个dll，美其名曰可以直接替换BLL层，这样和直接替换exe有多少区别？
ORM的时代还没到来：
ORM的思想很好，但是搞清楚，现在用的数据库是关系型数据库，不是对象型数据库，多余的转换，多余的代码，每次看到别人写的实体就想吐，操作个数据库直接执行sql就好了，用的着兜一圈吗，还要把数据库表转换为对象，其实ORM和linq另外一个好的思想是统一开发接口，比如多种数据源，但是实际上并非如此，软件往往只用到一个数据库，如果要用多数据库，用DoNet的接口写一个数据转换类就可以了，什么CSLA.NET,Hibernate之类的全是浮云，只能增大无用代码的输入量和开发时间，同时降低程序效率
不使用linq
不使用ORM
不盲目分层，让所谓的3层去死
软件可以分层，但绝不仅仅是多少层得问题，而是分层的思想是什么，最重要的是为什么要这样做？然后是怎么分层合适，什么逻辑层和UI分层，大多数人都是在盲从和误解，就像大众始终是盲目的一样，我只是想说要思考为什么要这么做，如果按照界面和逻辑分离的思想，自从vs2003之后微软就已经把程序分层了，因为以前的界面代码和窗体的.cs文件时在一起的，后来就分开了，这就是分层，不知从何时起有人有单独把逻辑处理从cs文件中剥离出来又单独作为一个dll，美其名曰可以直接替换BLL层，这样和直接替换exe有多少区别？
ORM的时代还没到来：
ORM的思想很好，但是搞清楚，现在用的数据库是关系型数据库，不是对象型数据库，多余的转换，多余的代码，每次看到别人写的实体就想吐，操作个数据库直接执行sql就好了，用的着兜一圈吗，还要把数据库表转换为对象，其实ORM和linq另外一个好的思想是统一开发接口，比如多种数据源，但是实际上并非如此，软件往往只用到一个数据库，如果要用多数据库，用DoNet的接口写一个数据转换类就可以了，什么CSLA.NET,Hibernate之类的全是浮云，只能增大无用代码的输入量和开发时间，同时降低程序效率
游不出缸的鱼 2011-09-20
- 打赏
- 举报
[Quote=引用 15 楼 fangxinggood 的回复:]
我个人习惯用var，重构代码时类名修改了也只修改右边。不是很好么。
这东西就是个习惯问题(向右看齐)。能省则省。
[/Quote]
已经习惯了就没有问题
可是如果代码还有别人维护，而且别人不习惯的话，这可能就是个问题了
另外你提到的“重构代码时类名修改了也只修改右边”，VS的重构-重命名功能不是可以一次性把类名的所有引用位置都改了么，也不需要特意去动左边啊
我个人习惯用var，重构代码时类名修改了也只修改右边。不是很好么。
这东西就是个习惯问题(向右看齐)。能省则省。
[/Quote]
已经习惯了就没有问题
可是如果代码还有别人维护，而且别人不习惯的话，这可能就是个问题了
另外你提到的“重构代码时类名修改了也只修改右边”，VS的重构-重命名功能不是可以一次性把类名的所有引用位置都改了么，也不需要特意去动左边啊
jackfans 2011-09-20
- 打赏
- 举报
var 挺乱的
机器人 2011-09-20
- 打赏
- 举报
我个人习惯用var，重构代码时类名修改了也只修改右边。不是很好么。
这东西就是个习惯问题(向右看齐)。能省则省。
这东西就是个习惯问题(向右看齐)。能省则省。
Icedmilk 2011-09-20
- 打赏
- 举报
这是中国软件开发的现状
极度缺乏专业的项目管理人员，现在的管理人员都太操蛋
[Quote=引用 13 楼 w1720502338 的回复:]
引用 11 楼 moneysoft 的回复:
楼主,是这样的,基于不同的生产手段,关注的焦点会有所不同,
可能会是很大的差别,
在一些拥有自动化测试手段的开发组织.
一个被提交的工单,是以自动化测试标定为合格,
一旦通过测试,不会有人再去看这些代码,
如果以后这个组件被证明存在缺陷,那也和最初提交工单的程序员没有任何关系了,
设计师会重构出新的设计文档接口,安排新的测试实现……
[/Quote]
极度缺乏专业的项目管理人员，现在的管理人员都太操蛋
[Quote=引用 13 楼 w1720502338 的回复:]
引用 11 楼 moneysoft 的回复:
楼主,是这样的,基于不同的生产手段,关注的焦点会有所不同,
可能会是很大的差别,
在一些拥有自动化测试手段的开发组织.
一个被提交的工单,是以自动化测试标定为合格,
一旦通过测试,不会有人再去看这些代码,
如果以后这个组件被证明存在缺陷,那也和最初提交工单的程序员没有任何关系了,
设计师会重构出新的设计文档接口,安排新的测试实现……
[/Quote]
游不出缸的鱼 2011-09-20
- 打赏
- 举报
[Quote=引用 11 楼 moneysoft 的回复:]
楼主,是这样的,基于不同的生产手段,关注的焦点会有所不同,
可能会是很大的差别,
在一些拥有自动化测试手段的开发组织.
一个被提交的工单,是以自动化测试标定为合格,
一旦通过测试,不会有人再去看这些代码,
如果以后这个组件被证明存在缺陷,那也和最初提交工单的程序员没有任何关系了,
设计师会重构出新的设计文档接口,安排新的测试实现和代码实现
在另一种更加自动化的方式下,甚至都……
[/Quote]
很成熟的开发体系啊
我们公司推的产品有很好的理念，市场前瞻性也不错
但是开发过程很让人崩溃啊，
没有需求文档、没有设计文档、代码几乎没有注释、没有测试文档、没有自动化测试
测试几乎完全依赖人工，经常发生回归现象
我想跟Boss提提意见（整个氛围比较轻松，直接跟Boss对话是比较容易的），改善下开发流程
但考虑到我所有关于开发流程的知识都是看来的，没有实践过，不太有说服力
而且这等于是说leader的管理有问题，恐日后尴尬
最近正为这事儿苦恼啊
楼主,是这样的,基于不同的生产手段,关注的焦点会有所不同,
可能会是很大的差别,
在一些拥有自动化测试手段的开发组织.
一个被提交的工单,是以自动化测试标定为合格,
一旦通过测试,不会有人再去看这些代码,
如果以后这个组件被证明存在缺陷,那也和最初提交工单的程序员没有任何关系了,
设计师会重构出新的设计文档接口,安排新的测试实现和代码实现
在另一种更加自动化的方式下,甚至都……
[/Quote]
很成熟的开发体系啊
我们公司推的产品有很好的理念，市场前瞻性也不错
但是开发过程很让人崩溃啊，
没有需求文档、没有设计文档、代码几乎没有注释、没有测试文档、没有自动化测试
测试几乎完全依赖人工，经常发生回归现象
我想跟Boss提提意见（整个氛围比较轻松，直接跟Boss对话是比较容易的），改善下开发流程
但考虑到我所有关于开发流程的知识都是看来的，没有实践过，不太有说服力
而且这等于是说leader的管理有问题，恐日后尴尬
最近正为这事儿苦恼啊
游不出缸的鱼 2011-09-20
- 打赏
- 举报
看来大家观点都跟我一致啊
我认为var是配合匿名类用的，因为它没有类名啊，只能用var，其他时候var就是个语法糖，看起来可以用来定义一切变量，但实际上是由编译器进行类型推断的，只不过是把写完整类名的事情交给编译器了，所以要在定义的时候初始化，不然怎么推断类型，楼上也说了C#是强类型的，变量必须有类型的。
一次leader看我敲代码，我都是写完整类名的，leader说，用var多好啊，打起来省事，在这种细节方面省下一点时间，累积起来就比较多了。我表示本人菜鸟一只，leader这么说，我以为经验之谈，但后来看到系统里大片var定义的变量，感觉挺别扭的，于是来看看大伙儿怎么说。
我认为var是配合匿名类用的，因为它没有类名啊，只能用var，其他时候var就是个语法糖，看起来可以用来定义一切变量，但实际上是由编译器进行类型推断的，只不过是把写完整类名的事情交给编译器了，所以要在定义的时候初始化，不然怎么推断类型，楼上也说了C#是强类型的，变量必须有类型的。
一次leader看我敲代码，我都是写完整类名的，leader说，用var多好啊，打起来省事，在这种细节方面省下一点时间，累积起来就比较多了。我表示本人菜鸟一只，leader这么说，我以为经验之谈，但后来看到系统里大片var定义的变量，感觉挺别扭的，于是来看看大伙儿怎么说。
加载更多回复（11）
