在与同事讨论了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 sb = new StringBuilder();

而不是:

StringBuilder sb = new StringBuilder();

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

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

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

其他回答

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

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

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

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

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

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

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

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

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

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

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

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

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