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


当前回答

静态类型是关于契约的,而不是源代码。这里的想法是需要将静态信息放在“应该”是一个小方法的单行上。一般指南建议每个方法不要超过25行。

如果一个方法足够大,以至于您无法跟踪该方法中的单个变量,那么您做错了其他事情,这将使任何对var的批评相形见绌。

实际上,var的一个重要论点是它可以使重构更简单,因为你不再需要担心你的声明过于严格(例如,当你应该使用IList<>或IEnumerable<>时,你使用了List<>)。您仍然需要考虑新的方法签名,但至少不必返回并更改声明来匹配。

其他回答

您可以让编译器(以及接下来维护代码的人员)从初始化式赋值的右边推断类型。如果这种推断是可能的,编译器可以这样做,从而节省了您的一些输入。

如果这个推断对那个可怜的家伙来说很容易,那么你没有伤害到任何东西。如果推断很难,那么作为一般规则,您已经使代码更难维护 我不会这么做的。

Lastly, if you intended the type to be something particular, and your initializer expression actually has a different type, using var means it will be harder for you to find the induced bug. By explicitly telling the compiler what you intend the type to be, when the type isn't that, you would get an immediate diagnostic. By sluffing on the type declaration and using "var", you won't get an error on the initialization; instead, you'll get a type error in some expression that uses the identifier assigned by the var expression, and it will be harder to understand why.

寓意是,要谨慎使用var;您通常不会给您自己或您的下游维护人员带来很多好处。并希望他的理由是一样的,这样你就不会因为他认为使用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,我就不必这样做。

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

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

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

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

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

梅菲

如果有人使用var关键字是因为他们不想“找出类型”,那肯定是错误的原因。var关键字不会创建动态类型的变量,编译器仍然需要知道该类型。由于变量总是具有特定的类型,因此如果可能的话,该类型在代码中也应该是明显的。

使用var关键字的理由如下:

在需要的地方,即声明匿名类型的引用。 它使代码更具可读性,即删除重复的声明。

写出数据类型通常会使代码更容易理解。它显示了您正在使用的数据类型,因此您不必通过先弄清楚代码的功能来弄清楚数据类型。

我不明白这有什么大不了的。

var something = someMethod(); // Type of 'something' not clear <-- not to the compiler!

你仍然对“某事”有完全的智能感知,对于任何不明确的情况,你都有单元测试,对吗?(是吗?)

它不是varchar,也不是dim,当然也不是动态或弱类型。它像这样阻止疯狂的人:

List<somethinglongtypename> v = new List<somethinglongtypename>();

把这些杂乱的思想归纳为:

var v = new List<somethinglongtypename>();

不错,但不如:

v = List<somethinglongtypename>();

但这就是布的作用。