Option Strict On 和 .NET 对于 VB6 程序员的意义

Question

我正在为面向 Visual Basic 6 程序员迁移到 .NET 平台的 Visual Basic 2005 准备一门课程。

关于是否建议他们始终启用 Option Strict ，我想征求一些建议。

我之前一直使用 C 风格的编程语言，主要是 Java 和 C#。因此，对我来说，显式类型转换 总是必须进行的操作，因为这从来不是一个选项。
然而，我认识到使用具有内置支持 后期绑定 的语言的价值，因为在代码中不需要过度明确类型确实可以节省时间。这通过流行的 动态类型语言 进一步证明了，即使在 Dynamic Language Runtime 下，.NET 平台上也如此。

考虑到这一点，对于第一次使用 VB.NET 并具有 VB6 背景的人，应该鼓励他们采用 编译时类型检查工作 的思维模式，因为这是 CLR 中的“最佳实践”吗？还是“好”的继续享受后期绑定的好处呢？

- Enrico Campidoglio

Answer 1

是的！选项严格模式（Option Strict）绝对是使用.Net的最佳实践。强调一下，.Net在其核心上是一个强类型平台，并且在DLR得到更完全支持之前仍将如此。除了像LINQ、Boo和JScript这样的情况外，每个Dim和Function几乎都应该有一个显式的类型声明。

以下是一些其他需要指出的事情。我相信你很清楚所有这些内容，但我不得不与许多由VB6编写的VB.Net代码一起工作和维护，所以这是我的敏感点：

• 不要再使用旧的字符串函数：LEN()，REPLACE()，TRIM()等。
• 不再推荐使用匈牙利命名法。 oMyObject和sMyString已经过时。如果他们不相信你，请向他们展示Microsoft设计准则中的参考文献。
• 确保他们了解新的AndAlso/OrElse逻辑运算符。
• 参数化查询和现代ADO.Net。无法强调此点。他们再也不需要调用CreateObject()了。
• 在.Net中，作用域的工作方式有所不同（并且更加重要）与VB6中的相比。VB.Net仍然有模块，但现在它们更类似于静态类。重要的是要了解如何在真正的面向对象的环境中开发，以区别于VB6提供的部分OOP支持。再也没有任何好理由允许方法运行到难以想象的长度。
• 确保他们介绍泛型和接口（包括IEnumeralbe(Of T)），并学习为什么他们再也不应该使用ArrayList了。

我还可以继续下去，但我将指向VB.Net隐藏功能问题来结束这个抱怨。

- Joel Coehoorn

---

每个 Dim 和 Function 都应该有一个明确的类型声明与之相匹配。- 不！“Option Infer On”来帮助解决这个问题（仅适用于Dim）。 - Konrad Rudolph

您的第一个观点的理由是错误的：没有调用VB6运行时！这些调用可能是多余的和不良的风格（不一致），但绝对不是恶意的。有些甚至具有实际优势（例如MsgBox）。 - Konrad Rudolph

我曾经试图寻找我读到过的关于MS.VB.dll调用旧运行时的信息，但是我找不到它，所以我只是完全删除了引用。 - Joel Coehoorn

不要告诉他们不要使用兼容性函数，而是告诉他们移除 Microsoft.VisualBasic 的全局导入。他们仍然可以通过键入完整的命名空间来使用旧函数，但这很费时且难看。这是一种使旧内容使用成本增加的好方法。 - Craig Gidney

在我看来，这并没有真正回答问题。如果没有启用Option Strict选项，编译器会自动进行转换，那么为什么要明确添加它们并且需要在每个地方额外添加约5%的代码呢？这是C类型语言所必需的，但对于VB.net，我真的看不出有什么优势。Option Explicit应该足以解决你关于类型声明的问题。 - yu_ominae

Answer 2

开启 Option Strict 进行开发所花费的时间，将为您节省后续大量调试时间。

- Ilya Kochetov

---

我同意。但是，像动态语言一样充分利用单元测试，难道不能减轻这种风险吗？ - Enrico Campidoglio

也许可以，但这些人正在从VB6迁移-您真的想同时引入单元测试吗？ - Carl

Answer 3

Option Strict显然不能取代良好的单元测试，反之亦然。虽然单元测试可以检测与Option Strict相同的错误，但这意味着单元测试中没有错误，单元测试经常且早期进行等等...

编写良好的单元测试并不总是简单的，需要花费时间。然而，编译器已经实现了一些测试 - 以类型检查的形式。至少，这可以节省时间。更有可能的是，这可以节省很多时间和金钱（至少偶尔），因为您的测试有误/未涵盖所有情况/忘记考虑代码更改。

总结一下，不能保证您的单元测试是正确的。另一方面，编译器执行的类型检查是正确的或者至少其故障（未经检查的数组协变、循环引用错误等）是众所周知和文档化的。

再次总结：是的，Option Strict On绝对是最佳实践。事实上，我在像这样的在线社区工作了多年。每当有人需要帮助明显没有启用Option Strict的代码时，我们会礼貌地指出并拒绝提供任何进一步的帮助，直到问题得到解决。这可以节省很多时间。通常，问题就此解决了。这有点类似于在HTML支持论坛中请求帮助时使用正确的HTML：无效的HTML可能有效，但也可能不起作用并成为问题的原因。因此，许多专业人士拒绝提供帮助。

- Konrad Rudolph

---

很棒的答案。我想补充的是在编译时将警告设置为错误处理。此外 - 在开发网站时，出于同样的原因，我将兼容性设置为最严格的水平（当前为文档类型 XHTML 1.1）。 - Rob Allen

同意。由于变量的显式转换而导致代码冗长的额外语言不足以与让编译器完成其工作所节省的大量时间相比。感谢您提供出色的答案！ - Enrico Campidoglio

Answer 4

是的！！！

在我看来，作为一名开发人员和大学讲师，是的。

最好从一开始就养成好习惯，这样整个过程会更容易，而且Option Strict是我认为必需的元素之一。

添加

可以列出无数个原因，但关键是它是最佳实践之一，当教授一门新语言时，关键是要从一开始就教授这些最佳实践。

- Mitchel Sellers

Answer 5

记住这里有两个级别。

Option Explicit Option Strict

两者之间的主要区别在于Option Strict禁用VB对不同数据类型的自动转换。您必须显式使用CType或另一个数据转换函数将变量分配给另一种类型。

我自VB 1.0以来一直在使用它，虽然我可以看出这一点，但我认为Strict在处理已实现或继承不同接口和类的对象时过于热衷。

我建议从Strict开始，如果它开始妨碍你，那么就降到Explicit。但是永远不要关闭两者，那样会导致疯狂和过多的调试时间。

多年来，我几乎将Double用于所有浮点变量。这样可以避免许多舍入和精度损失的问题。在VB6中，我使用long作为32位整数，但在.NET中，Integer同样有效，因为它是Int32。我还建议使用Int32，Int16等而不是Integer，Long等，以防Microsoft重新定义这些关键字。

- RS Conley

Answer 6

我不同意RS Conley的观点（这很少见）。我的VB6大师们——Francesco Balena和Dan Appleman都不喜欢VB6的自动转换，并且支持.NET中的Option Strict。在这里和这里可以看到他们的观点。许多有经验的VB6程序员都知道自动转换为“邪恶的类型强制转换”（pdf），并会乐意开启Option Strict。

偶尔使用一个没有Option Strict的小模块可能更好，以避免大量复杂的反射代码。但这是证明规则的例外情况。

- MarkJ

Answer 7

鉴于 Boehm 认为在开发周期早期解决问题消耗的资源最少，我支持每一种能够帮助开发人员尽早“做对”的工具。因此，我赞成像 IntelliSense 这样的工具，它不仅提高了效率，还可以帮助你在开发周期早期实现可工作的代码（但不一定是正确的）。

出于同样的原因，我也支持使用 Option Strict 作为一种方式来帮助保持错误步骤及其后续更正深入到“设计时间”。

- adengle

Answer 8

如果您习惯于进行类型检查，则可能希望启用选项严格模式。关闭它可能具有优点，但如果您的大脑没有调整到能够在编译器通常会发出警告的错误位置上发现错误，则建议您将其保持开启状态。我经常使用VB.Net，在大多数情况下都会关闭选项严格模式，但我见过很多情况，如果打开了它，就可以预防相当多的错误。

- Kibbee

---

嗯，也许你应该考虑打开 Option Strict ？！？ - MarkJ

是的，我愿意这样做，但在我的当前项目中，打开严格选项来修复所有错误可能需要数月时间。 - Kibbee