Question

可能重复：
  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 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无法告诉您推断类型的环境中工作，那么更多。
在这种情况下，推断类型最终可能会比您真正想要的更具体。

解决方法：在这种情况下专门声明您想要的类型。

当编译器捕获到这个问题的情况时，我不会称之为“危险”本身。我唯一能想到编译器没有捕到的问题，如果你对基类和派生类型的方法有不同的重载，或者是派生类型的阴影方法。我认为其中任何一种情况都是现有代码的问题，而不是选项推断。
LINQ查询中出现的匿名类型的使用可能导致比正常情况更大的方法，因为它们无法在方法之间传递。

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

尽管长期方法很危险，但这更具危险性。通常的“需要多长时间”的讨论适用。
这让我看起来效率较低，因为我的代码文件中的KB少于我不必输入的所有类型名称。（好吧，这个是个玩笑。）

Answer 2

越来越多的语言推断出其变量的类型。考虑C＃，F＃以及可能还有许多非.NET语言。

您使用option infer on保持类型安全。喜欢指定变量的人仍然可以这样做。但有时它几乎是不可能的，并且肯定会使阅读代码变得更难，使用LINQ时最终会出现这些神秘的名字。

我曾经是老派。但是当推断进入C＃世界时，过了一段时间我就不得不承认：它提高了编码速度，可读性，从而提高了质量，使维护代码变得更容易。这并不意味着您应该停止指定所有变量。在许多情况下，无论推断是打开还是关闭，指定类型仍然更好。再说一遍：为了便于阅读。

向老派人员解释默认情况下你想要它的原因，如果他们愿意，他们仍然可以输入类型名称。

Answer 3

在我的情况下，我更喜欢全部开启

但是Infer OFF是“ok”，你只需输入MORE; - ）

选项推断开还是关？

3 个答案: