在与同事讨论了c# 3中var关键字的使用后,我想知道人们对通过var适当使用类型推断的看法是什么?

例如,我很懒地在有问题的情况下使用var,例如:-

foreach(var item in someList) { // ... } // Type of 'item' not clear.
var something = someObject.SomeProperty; // Type of 'something' not clear.
var something = someMethod(); // Type of 'something' not clear.

var更合法的用法如下:-

var l = new List<string>(); // Obvious what l will be.
var s = new SomeClass(); // Obvious what s will be.

有趣的是,LINQ似乎是一个灰色区域,例如:-

var results = from r in dataContext.SomeTable
              select r; // Not *entirely clear* what results will be here.

结果很明显,因为它将是一个实现IEnumerable的类型,但它并不完全明显,与var声明一个新对象的方式相同。

当涉及到对象的LINQ时,情况就更糟了,例如:-

var results = from item in someList
              where item != 3
              select item;

这并不比等价的foreach(var item in someList){//…}相当于。

这里有一个关于类型安全的真正问题——例如,如果我们将该查询的结果放在一个接受IEnumerable<int>和IEnumerable<double>的重载方法中,调用者可能会无意中传入错误的类型。

Var确实保持强类型,但问题是,在定义中不立即显示类型是否危险,当重载意味着当你无意中将错误的类型传递给方法时,编译器可能不会发出错误,这种情况会被放大。


当前回答

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

如果你有一行代码,比如

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

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

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

其他回答

第一。

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

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

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

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

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

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

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

梅菲

@erlando,

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

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

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

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

我在以下情况下使用var:

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

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

Employee emp = new Employee() any more obvious?

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

var emp = GetEmployee();

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