.net - 选项推断开还是关？ [复制]

Question

这个问题已经在这里有了答案:




9年前关闭。

Possible Duplicate:
Best Practices: Option Infer
What is the best way to mix VB.NET's Option Strict and the new Option Infer directives?

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

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

Option Strict On
Option Explicit On

我想使用LINQ，发现Option Infer On也更容易使用。

写的更少，读的更少(因此更容易)。

但是，从我的角度来看，团队的一部分(保守的观点)使Option Infer Off处于关闭状态，并坚称根本不要使用Option Infer，除非明确说明原因。

您认为，使用Option Infer On以及其他两个选项(Strict和Explicit都为On)的“危险”是什么？

Answer 1

启用Option Infer编写的代码在性能或类型安全上与使用显式声明的相同类型编写的代码没有什么不同。考虑到这一点，我可以针对Option Infer提出的参数是:

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

即使内联初始化，也不能推断出一个的类字段。

包含lambda的变量(Dim f = Function(x) ...)并不总是推断类型。

未初始化的变量必须被赋予

类型

该参数的强度与现有代码库中样式的一致性成正比。 (例如，即使使用较新的编译器，即使我周围的其余代码都使用了下划线，但有时即使在较新的编译器不需要它们的情况下，我有时仍会使用下划线继续行。)

在浏览代码时，有时类型不是立即显而易见的。

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

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

这不是“危险”，而是潜在的不便。如果您不在Intellisense不能告诉您推断类型的环境中工作，则更应如此。

在这种情况下，推断出的类型最终可能比您真正想要的更具体。

解决方法:在这种情况下，明确声明所需的类型。

由于编译器在遇到问题时会遇到情况，因此我不会将其本身称为“危险”。我唯一能想到的是编译器无法解决的问题是，如果您对基本类型和派生类型的方法有不同的重载，或者在派生类型中使用了阴影方法。我认为这两种情况都是现有代码的问题，而不是Option Infer的问题。

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

解决方法:发生这种情况时，请定义命名类型，然后照常拆分方法。

只要有很长的方法是危险的，这更是一种危险。通常会进行“多长时间为多久”的讨论。

这使我的工作效率降低，因为所有不需要键入的类型名称中的代码文件中的KB都更少。 (好的，这是个玩笑。)