在与同事讨论了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确实保持强类型,但问题是,在定义中不立即显示类型是否危险,当重载意味着当你无意中将错误的类型传递给方法时,编译器可能不会发出错误,这种情况会被放大。


当前回答

它可以使代码更简单、更短,特别是对于复杂的泛型类型和委托。

此外,它使变量类型更容易更改。

其他回答

来自Essential LINQ:

除非绝对必要,否则最好不要显式声明范围变量的类型。例如,下面的代码编译干净,但是编译器可以在没有正式声明的情况下推断出类型:

List<string> list = new List<string> { "LINQ", "query", "adventure" };
var query = from string word in list
      where word.Contains("r")
      orderby word ascending
      select word;

显式声明range变量的类型会强制对LINQ Cast操作符进行幕后调用。此调用可能会产生意想不到的结果,并可能会损害性能。如果您在LINQ查询中遇到性能问题,像这里所示的强制转换可能是开始寻找罪魁祸首的一个地方。(此规则的一个例外是当您使用非泛型Enumerable时,在这种情况下您应该使用强制转换。)

有人不喜欢批评var..所有答案downmodded..哦. .

@Jon Limjap: 我知道。:)我的意思是可读性被降级了,就像在VB6一样。我不喜欢依靠智能感知来确定给定变量的类型。我希望能单独用源代码求出它。

命名惯例也没用——我已经用好名字了。我们要回到前缀时代吗?

在转换到3.0和3.5框架之后,我了解了这个关键字,并决定尝试一下。在提交任何代码之前,我意识到它似乎是向后的,就像回到ASP语法一样。所以我决定戳一下高层,看看他们怎么想。

他们说去吧,我就用了。

也就是说,我避免在类型需要一些调查的地方使用它,就像这样:

var a = 公司。获取记录();

现在它可能只是一个个人的事情,但我立即不能看,并确定如果它是一个记录对象的集合或一个字符串数组表示记录的名称。无论哪种情况,我认为显式声明在这种情况下是有用的。

var是处理匿名类型的方法,无论是否来自LINQ语句。任何其他用途在很大程度上取决于谁将阅读您的代码以及有哪些指导方针。

如果你是唯一的观众,或者你的观众对使用var很熟悉,或者非常熟悉你的代码,那么我想这没有关系。如果你像这样使用:var s = new SqlConnection(),那么这在很大程度上无关紧要,可能会提高代码的可读性。如果人们不太挑剔,他们可以做一些工作来了解不明显的类型(这在大多数情况下是不需要的,你在下面的语句中如何使用它通常会解释一切),那么它是好的。

但是如果你有挑剔的,思想封闭的队友,他们喜欢抱怨,或者如果你公司的设计准则特别禁止在类型不明显时使用var,那么你很可能会遇到强烈的反对。

如果使用var会让你的代码难以阅读,你可能会因为使用var而受到伤害,即使这可能是你的应用程序设计的问题。

如果var引入了歧义(有点像你的IEnumerable/IEnumerable例子),不要使用它,而是显式地使用它。但var确实有它的便利,在某些情况下,恕我直言,它甚至可以通过减少混乱来提高可读性。

我仍然认为var在某些情况下可以使代码更具可读性。如果我有一个带有Orders属性的Customer类,我想把它赋值给一个变量,我只需要这样做:

var orders = cust.Orders;

我不在乎顾客。Orders是IEnumerable<Order>, ObservableCollection<Order>或BindingList<Order> -我想要的只是将该列表保存在内存中,以便稍后对其进行迭代或获取其计数或其他内容。

将上述声明与:

ObservableCollection<Order> orders = cust.Orders;

对我来说,类型名只是噪音。如果我回头决定改变客户的类型。沿着轨道的订单(从ObservableCollection<Order>到IList<Order>),然后我也需要改变声明-如果我在第一个地方使用var,我就不必这样做。