.net 选项推断开还是关？

可能重复：

我正在开发一个旧的解决方案，它是从VB6转换到VB.NET的

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

Option Strict On
Option Explicit On

我想使用LINQ，并且发现在上使用

选项推断更容易

写的越少，读的越少（因此，越容易）

然而，团队中的一部分（保守的，从我的观点来看）拒绝使用推断选项，并坚持在没有明确解释原因的情况下根本不使用它

在您看来，使用Option Expert On以及其他两个选项（严格和明确，均为On）的“危险”是什么？
在我的情况下，我更倾向于使用all On

但是推断是“好的”，您只需要输入更多；-）
 越来越多的语言推断其变量的类型。考虑C，F，以及可能的所有非.NET语言。
您可以通过启用
选项推断来保持类型安全。喜欢指定变量的人仍然可以这样做。但有时这几乎是不可能的，而且肯定会使阅读代码变得更加困难，因为在使用LINQ时会出现那些神秘的名称

我以前是个守旧派。但是，当推断进入C#世界时，过了一段时间，我不得不承认：它提高了编码速度、可读性，从而提高了质量，并使代码维护更加容易。这并不意味着您应该停止指定所有变量。在许多情况下，无论“推断”是启用还是禁用，都最好指定类型。再说一遍：为了可读性

向老派人士解释为什么默认情况下您希望它打开，并且如果他们愿意，他们仍然可以键入这些类型名称。
使用选项编写的代码推断打开与使用明确声明的相同类型编写的代码在性能或类型安全性方面没有什么不同。考虑到这一点，我可以针对
选项推断提出以下论点：


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


无法推断一个的类字段，即使已内联初始化
持有lambda的变量（
Dim f=Function（x）…
）并不总是推断类型
必须为未初始化的变量指定类型

此参数的强度与现有代码库中样式的一致性成正比。（例如，在处理旧代码时，即使新编译器不需要下划线，如果周围的其他代码使用下划线，我有时也会使用下划线来继续行。）

有时，在查看代码时，类型并不是很明显

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

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

这与其说是一种“危险”，不如说是一种潜在的不便。如果您不是在Intellisense无法告诉您推断类型的环境中工作，则情况会更糟

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

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

当编译器发现这是一个问题时，我不会将其称为“危险”。我能想到的唯一一次编译器没有捕捉到的问题是，如果基类型和派生类型的方法具有不同的重载，或者是派生类型中的阴影方法。我认为这两种情况都是现有代码的问题，而不是选项推断的问题

使用LINQ查询中出现的匿名类型可能会导致比普通方法更大的方法，因为它们不能在方法之间传递

解决方法：在发生这种情况时定义命名类型，并按正常方式分解方法

这是一个更大的危险，因为长的方法是危险的。通常的“多长时间太长”讨论适用

这让我看起来效率不高，因为我的代码文件中有更少的KB来自所有我不必键入的类型名。（好的，这是一个笑话。）

我总是关闭
选项推断。但是，是的，我是一个老派和“保守”当谈到这样的事情。我宁愿编译器捕捉我的错误，而不是在运行时调试它们。我不介意额外的打字；在智能感知和快速打字之间，这不是什么大问题。至于另外两个，绝对没有借口：
Option Explicit
和
Option Strict
应该始终处于启用状态。@CodyGray，这是推断，推断工作，就像c#中的var一样，这是所有投票关闭的人的编译时错误捕获“不具建设性”，我建议将你的投票改为“完全重复”“：或者我真的不确定这怎么可能是客观的。唯一的目标将包含在
选项推断
指令的文档中。客观地说，不管它做什么，只要打开或关闭它，就会改变什么。其他一切都是风格和固有的主观。并不是说谈论风格有什么坏处。