6

可能重复：
最佳实践：Option Infer
混合 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）有什么“危险”？

4

3 回答 3

8

使用Option Inferon 编写的代码在性能或类型安全方面与使用显式声明的相同类型编写的代码没有区别。考虑到这一点，我可以提出反对的论点Option Infer是：

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

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

    这个论点的强度与现有代码库中风格的一致性成正比。（例如，在处理旧代码时，即使新的编译器不需要它们，如果周围的其余代码使用它们，我有时仍然使用下划线来继续行。）

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

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

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

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

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

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

    当编译器捕捉到这是一个问题的情况时，我不会将其称为“危险”本身。我唯一能想到编译器没有捕捉到的问题是，如果您对基类型和派生类型的方法有不同的重载，或者在派生类型中隐藏方法。我认为这两种情况都是现有代码的问题，而不是 Option Infer 的问题。

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

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

    与长方法一样危险，这更危险。通常的“多长时间太长”讨论适用。

  • 这让我看起来效率低下，因为我的代码文件中的所有不需要输入的类型名称的 KB 都更少。（好吧，这是一个笑话。）

于 2011-12-19T17:47:57.703 回答
3

越来越多的语言推断其变量的类型。考虑 C#、F# 以及可能还有一大堆非 .NET 语言。

您使用option infer on. 喜欢指定变量的人仍然可以这样做。但有时这几乎是不可能的，并且肯定会使阅读代码变得更加困难，因为在使用 LINQ 时最终会使用那些神秘的名称。

我曾经是老派。但是当推理进入 C# 世界时，过了一段时间我不得不承认：它提高了编码速度、可读性和质量，并且更容易维护你的代码。这并不意味着您应该停止指定所有变量。在许多情况下，最好指定类型，不管 infer 是打开还是关闭。再次：为了可读性。

向老派人士解释为什么您希望默认启用它，并且如果他们愿意，他们仍然可以在那里输入类型名称。

于 2011-12-19T15:37:35.063 回答
1

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

但是推断关闭是“好的”，你只需要输入更多;-)

于 2011-12-19T15:31:41.850 回答