我正在准备一个Visual Basic 2005上的一个类,目标是Visual Basic 6程序员迁移到.NET平台.
我想就是否建议他们始终启用Option Strict提出建议.
我专门使用C风格的编程语言,主要是Java和C#,所以对我来说,显式的转换是我一直希望我必须做的事情,因为它从来都不是一个选择.
但是我认识到使用内置支持后期绑定的语言的价值,因为不必过分明确代码中的类型确实可以节省时间.动态类型语言的流行扩散进一步证明了这一点即使在具有动态语言运行时的.NET平台上也是如此.
考虑到这一点,如果第一次使用VB.NET和VB6背景接近.NET的人应该被鼓励进入必须使用编译时类型检查的思维模式,因为这是"最佳实践". CLR？或者继续享受后期约束的好处是"还可以"吗？
是! Option Strict绝对是.Net的最佳实践.强调.Net是强类型平台的核心,直到DLR得到更完全的支持.除了少数例外,每一个Dim和Function应该申报去用它一个明确的类型.LINQ或Boo和JScript之类的东西是证明规则的例外.
以下是其他一些要点.我相信你很清楚这一切,但是我必须使用并维护很多由前VB6ers编写的VB.Net代码,所以这对我来说是一个痛处:
不要使用旧字符串函数:LEN(),REPLACE(),TRIM(),等
不再推荐匈牙利疣. oMyObject而且sMyString不是犹太人.如果他们不相信您,请在Microsoft的设计指南中向他们展示参考.
确保他们了解新的AndAlso/ OrElse逻辑运算符
PARAMETERIZED QUERIES和现代ADO.Net.不能强调这一点.他们永远不需要再打电话CreateObject().
范围在.Net中的工作方式与在VB6中的工作方式不同(并且更为重要).VB.Net仍然有模块,但它们现在更类似于静态类.理解在真实面向对象环境中的开发是如何不同的,而不是VB6提供的部分OOP支持.没有充分的理由允许方法运行到不合适的长度.
确保他们获得泛型和接口(包括IEnumeralbe(Of T))的介绍,并了解他们为什么不再使用ArrayList.
我可以继续前进,但我会指出你对VB.Net问题的隐藏功能,以结束这个咆哮.
使用Option Strict启用开发所花费的时间将为您节省大量的调试时间.
Option Strict显然不能取代好的单元测试 - 但是反过来也没有.虽然单元测试可以检测到相同的错误Option Strict,但这意味着单元测试中没有错误,单元测试经常和早期完成等等.
编写好的单元测试并不总是微不足道的,需要时间.但是,编译器已经实现了一些测试 - 以类型检查的形式.至少,这节省了时间.更可能的是,这节省了大量的时间和金钱(至少偶尔),因为您的测试是错误的/未涵盖所有情况/忘记考虑代码中的更改.
总结一下,无法保证您的单元测试是正确的.另一方面,有一个强有力的保证,编译器执行的类型检查是正确的,或者至少是它的毛刺(未经检查的数组协方差,带有循环引用的错误......)是众所周知的并且已有详细记录.
另一个总结:是的,Option Strict On绝对是最好的做法.事实上,我在这样的在线社区工作多年.每当有人需要帮助显然没有Option Strict启用的代码时,我们会礼貌地指出这一点,并拒绝提供任何进一步的帮助,直到修复.它节省了很多时间.通常,问题在此之后就消失了.这有点类似于在HTML支持论坛中寻求帮助时使用正确的HTML:无效的HTML可能有用,但话说再次,它可能不是问题的原因.因此,许多专业人士拒绝提供帮助.
是!!!!
在我看来,无论是作为开发人员还是作为大学讲师都是.
最好从一开始就养成良好的习惯,它使整个过程变得更加容易,而Option Strict是我认为需要的元素之一.
添加
有很多原因可以列举为什么,但关键是它是一种最佳实践,并且在教授新语言时,从一开始就教授这些最佳实践是关键.
京公网安备 11010802040832号 | 京ICP备19059560号-6 