Option Infer开启或关闭？

Question

我是一名有用的助手，可以为您翻译以下内容：

可能是重复的：
最佳实践：Option Infer
混合使用VB.NET的Option Strict和新的Option Infer指令的最佳方法是什么？

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

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

Option Strict On
Option Explicit On

我想使用LINQ，并发现开启Option Infer On更加容易使用。

写的更少，阅读也更少（因此更容易）。

然而，小组中保守的一部分（从我的角度看）坚持关闭Option Infer并且没有明确说明原因。

在您看来，开启Option Infer On以及同时开启另外两个选项（Strict和Explicit，都为On）可能存在什么“危险”？

- serhio

---

我总是关闭 Option Infer 选项。但是，是的，对于这类事情，我比较“老派”和“保守”。我宁愿让编译器捕获我的错误，而不是在运行时进行调试。我不介意多打几个字；因为 IntelliSense 和快速打字，所以这不是什么大问题。 - Cody Gray

对于另外两个选项，绝对没有任何借口：Option Explicit 和 Option Strict 应该始终开启。 - Cody Gray

@CodyGray，这是一个名为“infer”的东西，它的作用类似于C#中的var。这个错误在编译时被捕获了。 - Fredou

针对所有投票"不具建设性"的人，我建议将您的投票改为"完全重复"：最佳实践：Option Infer或者如何混合使用VB.NET的Option Strict和新的Option Infer指令？。 - Cody Gray

@Cody Gray：那么客观的（非主观的）观察差异呢？ - serhio

Answer 1

Option Infer开启的代码在性能和类型安全方面与显式声明相同类型的代码没有区别。考虑到这一点，我可以想到反对Option Infer的几个理由：

• Inconsistency between cases when the type must be specified and when it can be inferred.

  • Class fields for one cannot be inferred, even if initialized inline.
  • Variables holding lambdas (Dim f = Function(x) ...) do not always infer types.
  • Variables that are not initialized must be given a type

  The strength of this argument is directly proportional to the consistency of style in your existing codebase. (For example, I sometimes still use underscores to continue lines when working with older code even when the newer compiler does not require them, if the rest of the code around it uses them.)

• Sometimes the type is not immediately obvious when looking through code.

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

  Workaround: Declare the variable's type when you feel the need.

  This is not a "danger" as much as a potential inconvenience. More so if you are not working in an environment where Intellisense cannot tell you the inferred type.

• The inferred type may end up being more specific than you really want in that case.

  Workaround: Specifically declare the type you want in that case.

  As the compiler catches cases when this is an issue, I wouldn't call it a "danger" per se. The only time I can think of where this would be an issue the compiler doesn't catch would be if you have different overloads of a method for the base and derived types or are shadowing methods in a derived type. I would argue that either of those cases are problems with the existing code and not with Option Infer.

• The usage of anonymous types that come up in LINQ queries could lead to larger methods than normal as they cannot be passed between methods.

  Workaround: Define named types when this occurs and break up methods as normal.

  This is more of a danger in as much as long methods are dangerous. The usual "how long is too long" discussions apply.

• It makes me look less productive because there are fewer KB in my code files from all those type names I don't have to type. (OK, this one is a joke.)

- Gideon Engelberth

Answer 2

越来越多的语言推断出其变量的类型，例如C#、F#以及许多非.NET语言。 通过使用，您可以保持类型安全。喜欢指定变量的人仍然可以这样做。但有时，这几乎是不可能的，并且使用LINQ时会使代码阅读更加困难，因为您最终会得到那些神秘的名称。 我曾经是老派的。但当推断进入C#世界后，过了一段时间，我只能承认：它提高了编码速度、可读性和代码质量，使维护代码变得更加容易。但这并不意味着您应该停止指定所有变量的类型。在许多情况下，指定类型仍然更好，无论是开启还是关闭推断。再次强调：为了可读性。 向老派人士解释为什么您希望默认开启它，并告诉他们如果他们愿意仍然可以输入其类型名称。

- Abel

Answer 3

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

但关闭推理也是可以的，你只需要多输入一些内容 ;-)

- Fredou