这个问题已经在这里有了答案:
9年前关闭。
我正在开发一个旧的解决方案，该解决方案已从VB6转换为VB.NET。
实际上，文件中的默认选项是
Option Strict On
Option Explicit On
我想使用LINQ，发现
Option Infer On也更容易使用。写的更少，读的更少(因此更容易)。
但是，从我的角度来看，团队的一部分(保守的观点)使Option Infer Off处于关闭状态，并坚称根本不要使用Option Infer，除非明确说明原因。
您认为，使用Option Infer On以及其他两个选项(Strict和Explicit都为On)的“危险”是什么？
最佳答案
启用Option Infer编写的代码在性能或类型安全上与使用显式声明的相同类型编写的代码没有什么不同。考虑到这一点，我可以针对Option Infer提出的参数是:
Dim f = Function(x) ...)并不总是推断类型。 该参数的强度与现有代码库中样式的一致性成正比。 (例如，即使使用较新的编译器，即使我周围的其余代码都使用了下划线，但有时即使在较新的编译器不需要它们的情况下，我有时仍会使用下划线继续行。)
Dim temp = Foo() 'temp is type of Foo's return, which is...
解决方法:在需要时声明变量的类型。
这不是“危险”，而是潜在的不便。如果您不在Intellisense不能告诉您推断类型的环境中工作，则更应如此。
解决方法:在这种情况下，明确声明所需的类型。
由于编译器在遇到问题时会遇到情况，因此我不会将其本身称为“危险”。我唯一能想到的是编译器无法解决的问题是，如果您对基本类型和派生类型的方法有不同的重载，或者在派生类型中使用了阴影方法。我认为这两种情况都是现有代码的问题，而不是Option Infer的问题。
解决方法:发生这种情况时，请定义命名类型，然后照常拆分方法。
只要有很长的方法是危险的，这更是一种危险。通常会进行“多长时间为多久”的讨论。