选项推断开还是关？

Question

可能重复:
最佳实践:选项推断
混合VB.NET的Option Strict和新的Option Infer指令的最佳方法是什么？

我正在开发一个旧的解决方案,从VB6转换为VB.NET.

实际上,文件中的默认选项是

Option Strict On
Option Explicit On

我想使用LINQ,并发现它也更容易使用Option Infer On.

写得少,阅读少(更容易).

然而,(保守的,从我的观点来看)团队的一部分保持Option Infer Off并且坚持不使用它,而没有明确解释原因.

在您看来,使用Option Infer On的"危险"是什么,以及其他两个选项(Strict和Explicit,都是On)？

Answer 1

使用Option Inferon 编写的代码在性能或类型安全性上与使用明确声明的相同类型编写的代码没有区别.考虑到这一点,我可以提出的论点Option Infer是:

• 必须指定类型和可以推断类型的情况之间的不一致.

  • 即使初始化为内联,也无法推断出一个类字段.
  • 持有lambdas(Dim f = Function(x) ...)的变量并不总是推断类型.
  • 未初始化的变量必须为类型

  此参数的强度与现有代码库中样式的一致性成正比.(例如,即使较新的编译器不需要它们,如果其周围的其余代码使用它们,我有时仍会使用下划线来处理旧代码时使用旧代码.)

• 在查看代码时,有时候类型并不是很明显.

  Dim temp = Foo() 'temp is type of Foo's return, which is...
  

  解决方法:在您需要时声明变量的类型.

  这不是一种"危险",而是一种潜在的不便.更重要的是,如果您不在Intellisense无法告诉您推断类型的环境中工作.

• 在这种情况下,推断类型可能最终会比您真正想要的更具体.

  解决方法:在这种情况下专门声明所需的类型.

  由于编译器在遇到问题时会抓住案例,因此我不会将其称为"危险".我唯一能想到编译器没有捕获的问题,如果你对基类和派生类型的方法有不同的重载,或者是派生类型的阴影方法.我认为其中任何一种情况都是现有代码的问题,而不是选项推断.

• LINQ查询中出现的匿名类型的使用可能会导致比正常方法更大的方法,因为它们无法在方法之间传递.

  解决方法:在发生这种情况时定义命名类型并正常分解方法.

  只要长时间的方法很危险,这就更具危险性了.通常的"需要多长时间"讨论适用.

• 这让我看起来效率降低,因为我的代码文件中的KB少于我不必键入的所有类型名称.(好吧,这个是开玩笑.)

Answer 2

就我而言，我更喜欢全部打开

但是关闭 Infer 就“ok”了，你只需要输入 MORE ;-)