针对.NET程序员的选项严格On和VB6

Question

我正在准备一个针对迁移到.NET平台的Visual 6程序员的Visual 2005类。

我想就是否推荐它们始终启用选项(严格的)提供一些建议。

我只使用C风格的编程语言，主要是Java和C#，所以对我来说，显式转换是我一直希望必须做的事情，因为它从来都不是一种选择。

不过，我认识到使用支持晚绑定的内置语言的价值，因为不必过分明确代码中的类型确实可以节省时间。动态类型化语言的流行传播进一步证明了这一点，即使在带有动态语言运行时的.NET平台上也是如此。

考虑到这一点，是否应该鼓励首次使用.NET并具有VB6背景的人进入必须使用编译时类型检查的心态，因为这是CLR中的“最佳实践”？或者继续享受后期绑定的好处是“可以”的？

Answer 1

是!选项严格绝对是.Net的最佳实践。强调.Net是它的核心是一个强类型的平台，并且将一直到DLR得到更完全的支持。除少数例外情况外，每个Dim和Function都应该声明一个显式类型来与它一起使用。像LINQ、Boo和JScript这样的东西是证明规则的例外。

以下是一些需要指出的其他事情。我相信您很清楚这一切，但是我不得不使用和维护许多由前VB.Net编写的VB6ers代码，所以这对我来说是个痛处：

• 不要使用旧的字符串函数：LEN()、REPLACE()、TRIM()等
• 匈牙利疣不再被推荐。oMyObject和sMyString不是犹太人。如果他们不相信你，给他们看微软的设计指南中的参考。
• 确保他们了解新的AndAlso/OrElse逻辑运算符
• 参数化查询和现代ADO.Net。怎么强调都不为过。他们再也不需要调用CreateObject()了。
• 范围在.Net中的工作方式与在VB6中不同(而且更重要)。VB.Net仍然有模块，但它们现在更类似于静态类。与VB6提供的部分OOP支持不同，理解在实际的面向对象环境中开发是多么的不同是很重要的。再也没有充分的理由允许方法运行到不虔诚的长度。
• 确保他们了解泛型和接口(包括IEnumeralbe(Of T))，并了解为什么再也不应该使用ArrayList。

我可以继续说下去，但我只想指出VB.Net的隐藏特征的问题来结束这个咆哮声。

Answer 2

使用选项严格启用开发所花费的时间以后将为您节省大量的调试时间。

Answer 3

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

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

总之，不能保证单元测试是正确的。另一方面，可以有力地保证编译器执行的类型检查是正确的，或者至少保证它的故障(未检查的数组协方差、循环引用的bug(…) )。都是有名的和有记载的。

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