我正在准备一个关于Visual Basic 2005的类，面向迁移到.NET平台的Visual Basic 6程序员。

我想就是否建议他们始终启用选项"严格"提出一点建议。

我只使用C风格的编程语言，主要是Java和C语言，所以对于我来说，明确的铸造是我一直期望的，因为它从来不是一个选项。
然而，我认识到使用支持后期绑定的语言的价值，因为不必对类型进行过多的明确说明。代码确实节省了时间。动态类型化语言的流行传播进一步证明了这一点，甚至在带有动态语言运行时的.NET平台上也是如此。< BR>考虑到这一点，是否应该鼓励第一次使用vb.net并具有vb6背景的人进入必须使用编译时类型检查的思维模式，因为这是clr中的"最佳实践"？或者继续享受后期绑定的好处是"可以"的吗？

对！选项严格绝对是.NET的最佳实践。强调.NET是它的核心，是一个强类型的平台，在DLR得到更全面的支持之前。除了极少数例外，每个Dim和Function都应该声明一个显式类型以与之匹配。像linq或boo和jscript之类的东西是证明规则的异常。

这里还有一些其他的事情要指出。我相信你很清楚这一切，但我必须使用和维护许多以前的vb6ers编写的vb.net代码，所以这对我来说是个痛处：

• 不要使用旧的字符串函数：LEN()、REPLACE()、TRIM()等
• 匈牙利疣不再被推荐。以东x1〔5〕和以东x1〔6〕不洁。如果他们不相信你，请在微软的设计指南中向他们展示参考资料。
• 确保他们了解新的AndAlso/OrElse逻辑运算符
• 参数化查询和现代ADO.NET。强调的不够。他们不应该再打电话给CreateObject()。
• 范围在.NET中的工作方式与在VB6中不同(而且更重要)。NET仍然有一些模块，但它们现在更类似于静态类。与VB6提供的部分OOP支持不同，了解在真实的面向对象环境中开发是如何不同的是很重要的。再也没有充分的理由允许方法运行到异常的长度。
• 确保他们了解了泛型和接口(包括IEnumeralbe(Of T))的介绍，并了解为什么他们不应该再使用ArrayList。

我可以继续说下去，但我将向您指出vb.net问题的隐藏特性，以结束这一咆哮。

使用选项strict enable开发所花的时间将为您节省大量的调试时间。

显然，Option Strict不能取代好的单元测试——但两者都不能替代。虽然单元测试可以检测到与Option Strict相同的错误，但这意味着单元测试中没有错误，单元测试经常和早期进行，等等……

编写好的单元测试并不总是琐碎的，而且需要时间。但是，编译器已经以类型检查的形式实现了一些测试。至少，这节省了时间。更可能的是，这节省了大量的时间和金钱(至少偶尔)，因为您的测试是错误的/没有涵盖所有的情况/忘记解释代码的更改。

综上所述，不能保证您的单元测试是正确的。另一方面，有一个强有力的保证，即编译器执行的类型检查是正确的，或者至少它的错误(未检查的数组协方差、带有循环引用的错误…)是众所周知的，并且有良好的文档记录。

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

对！！！！！

在我看来，无论是作为一个开发商，还是作为一名大学教师，都是的。

最好从一开始就养成好习惯，这会使整个过程更容易，而选项严格是我认为需要的要素之一。

补充

从字面上讲，有很多理由可以列出原因，但关键是它是一种最佳实践，而当教一种新语言时，从一开始就教那些最佳实践是关键。

记住这里有两个层次。

选项显式选项严格

两者之间的主要区别在于，选项strict禁用vb对不同数据类型的自动转换。您必须显式地使用ctype或其他数据转换函数将变量赋给其他类型。

我从1.0开始使用vb，虽然我看到了这一点，但我认为在处理已经实现或继承了不同接口和类的对象时，strict过于狂热。

我会从严格开始，如果它开始妨碍你的方式，然后下降到明确。但不要同时关闭，这样会导致疯狂和过多的调试时间。

在使用vb的多年中，我几乎对所有浮点变量都使用double。这样可以避免舍入和精度损失方面的许多问题。在vb6中，只要它是32位整数，我就使用它，但整数在.NET中的工作效果和在Int32中一样好。我还建议使用int32、int16等代替整数、long等，以防微软决定重新定义这些关键字。

我不同意康利的观点(非常不寻常)。我最喜欢的vb6大师——弗朗西斯科·巴勒纳，丹·阿普尔曼——都不喜欢vb6的自动转换，而且喜欢.NET中的Option Strict。许多有经验的vb6程序员都知道自动转换是"邪恶的类型强制"(pdf)，他们很乐意打开Option Strict。

偶尔最好使用一个没有Option Strict的小模块，以避免许多复杂的反射代码。但这是证明这一规则的例外。

考虑到Boehm认为在开发周期的早期修复一个问题会消耗最少的资源，我是所有帮助开发人员尽早"正确"的工具的粉丝。出于这个原因，我是IntelliSense之类的东西的倡导者，它既是提高效率的工具，也是帮助您在周期早期实现工作代码的工具。(有效，但不一定正确。)

出于这个原因，我还支持使用选项严格作为一种方法，以帮助将错误和随后的更正深入到"设计时"。

如果您习惯于检查您的类型，那么您可能希望对选项进行严格的检查。关闭它可能有好处，但是如果你的大脑没有调整到发现编译器通常会抱怨的错误，那么我会说让它开着。我在vb.net上做了很多工作，我不得不说，尽管我大部分时间都在严格关闭选项，但我已经看到很多情况下，打开它可以防止很多错误。