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

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

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

• LEN() , REPLACE() TRIM() 等
• 匈牙利疣不再被推荐。 oMyObject sMyString 我们不是犹太教徒。向他们显示中的引用 Microsoft's Design Guidelines
• 确保他们了解新产品 AndAlso / OrElse 逻辑运算符
• CreateObject() 再一次
• 作用域在.Net中的工作方式与在VB6中不同(而且更重要)。Net仍然有模块,但它们现在更类似于静态类。与VB6提供的部分OOP支持不同,理解在真正的面向对象环境中开发是如何不同是很重要的。再也没有理由允许方法运行到令人不快的地步了。
• 确保他们了解泛型和接口(包括 IEnumeralbe(Of T) ),并了解他们为什么不应该使用 ArrayList 再一次

Hidden Features of VB.Net 结束这场咆哮的问题。

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

Option Strict 显然不能取代好的单元测试,但反过来也不行。而单元测试 检测与相同的错误 选项严格

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

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

另一个总结是: 对 Option Strict On 事实上,我已经在这样的在线社区工作了很多年。当有人需要代码方面的帮助时,显然没有 选项严格 如果启用,我们会礼貌地指出这一点,并拒绝提供任何进一步的帮助,直到这一问题得到解决。它节省了很多时间。通常,这个问题在这之后就消失了。这在某种程度上类似于在HTML支持论坛中请求帮助时使用正确的HTML:无效的HTML可能有效,但同样,它可能无效,并且是问题的原因。因此,许多专业人士拒绝提供帮助。

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

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

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

记住这里有两个层次。

选项显式

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

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

我不同意你的观点 RS Conley in favour 属于 Option Strict pdf 选项严格 .

偶尔最好使用一个小模块,而不使用 选项严格

考虑到Boehm的观点,即在开发周期的早期修复问题消耗的资源最少,我是所有帮助开发人员尽早“正确处理”的工具的粉丝。出于这个原因,我提倡像IntelliSense这样的东西,它既是一种提高效率的工具,也是一种帮助您在周期的早期实现工作代码的工具。(工作,但不工作) 正确。)

出于这个原因,我还支持使用Option Strict作为一种帮助将错误和随后的纠正深入到“设计时”的方法