用于VB6程序员的.NET和.NET选项

我正在准备一门关于Visual Basic 2005的课程，目标是迁移到.NET平台的Visual Basic 6程序员。

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

我只使用过C风格的编程语言，主要是Java和C#，因此对我来说，显式转换是我一直希望必须做的事情，因为它从来都不是一个选项。
但是我认识到使用内置支持后期绑定的语言的价值，因为不必对代码中的类型过于明确确实节省了时间。动态类型语言的普及进一步证明了这一点，即使在使用动态语言运行时的.NET平台上也是如此。

---

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

使用Option Strict enable进行开发所花费的时间将为您以后节省大量调试时间。

是的

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

最好从一开始就养成良好的习惯，这会使整个过程变得更加容易，在我看来，严格选择是其中一个必要的因素

增加

---

原因有很多，但关键是这是一种最佳实践，在教授一门新语言时，从一开始就教授这些最佳实践是关键。

如果你习惯于检查你的类型，那么你可能希望选项严格。关闭它可能有好处，但如果你的大脑没有调整到发现编译器通常会抱怨的错误，那么我会说让它保持开启状态。我在VB.Net中工作过很多次，我不得不说，尽管我在大多数情况下使用的是关闭的options strict，但我见过很多情况，打开它可以防止很多bug。

Option strict

显然不能取代好的单元测试，但反过来也不行。虽然单元测试可以检测到与

Option Strict

相同的错误，但这意味着单元测试中没有错误，单元测试是经常和早期完成的，等等

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

总之，不能保证单元测试是正确的。另一方面，有一个强有力的保证，即编译器执行的类型检查是正确的，或者至少它的小故障（未检查的数组协方差、带有循环引用的bug…）是众所周知的，并且有很好的文档记录

---

另一个总结是：是的，

选项严格遵守

绝对是最佳实践。事实上，我已经在类似这样的在线社区工作多年了。每当有人需要关于显然没有启用

选项Strict

的代码的帮助时，我们会礼貌地指出这一点，并拒绝提供任何进一步的帮助，直到问题得到解决。它节省了很多时间。通常，这个问题在这之后就消失了。这在某种程度上类似于在HTML支持论坛中请求帮助时使用正确的HTML：无效的HTML可能有效，但同样，它可能无效，并且是问题的原因。因此，许多专业人士拒绝帮助。

是的！Option Strict绝对是.Net的最佳实践。强调.Net的核心是一个强类型平台，在DLR得到更全面的支持之前，它将一直处于核心地位。除了少数例外，每个

Dim

和

函数都应该声明一个显式类型以与之配套。像LINQ或Boo和JScript之类的东西是证明这一规则的例外

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


不要使用旧的字符串函数：
LEN（）
、
REPLACE（）
、
TRIM（）
等
匈牙利疣不再被推荐
MyObject
和
sMyString
是不洁的。如果他们不相信你的话，就给他们看参考资料
确保他们了解新的
和ALSO
/
或ELSE
逻辑运算符
参数化查询和现代ADO.Net。这一点怎么强调都不过分。他们不需要再次调用
CreateObject（）
作用域在.Net中的工作方式与在VB6中不同（而且更重要）。Net仍然有模块，但它们现在更类似于静态类。与VB6提供的部分OOP支持不同，理解在真正的面向对象环境中开发是如何不同是很重要的。再也没有理由允许方法运行到令人不快的地步了
确保他们了解泛型和接口（包括
IEnumeralbe（Of T）
），并了解为什么他们不应该再使用
ArrayList

我可以继续说下去，但我只想向你指出一个问题来结束这场喧嚣。
记住这里有两个层次

选项显式
选项严格

两者之间的主要区别是选项严格禁用VB对不同数据类型的自动转换。您必须显式使用CType或其他数据转换器