更改选项严格设置

时间:2014-05-14 17:11:51

标签: vb.net

我正在开发一个大型VB.NET应用程序'Option Strict'设置为off(由前一个开发人员设置)。我正在考虑将其设置为开启。这样做是否明智?我想确定是否应该:

  1. 保持原样。任何新的VB.NET应用程序都将选项严格设置为true
  2. 更改
  3. 我在MSDN上找不到任何关于此的指导。我读到Option Strict是为了帮助VB6开发人员过渡到VB.NET。

    我知道需要进行大量更改。我想确定它是否值得。

1 个答案:

答案 0 :(得分:4)

有一个新的Option Infer设置,有时可以关闭Option Strict(因为Option Infer取代了Option Strict,使其无效)。

您可能会发现此MSDN文章有用:

  

http://msdn.microsoft.com/en-us/library/bb384665.aspx

缺席选项推断,在大多数情况下,我强烈建议使用Option Strict。但是,你需要小心,只需打开它。即使您修复了出现的任何新编译器错误,将现有项目从Option Strict Off更改为Option Strict On也会导致 runtime 异常,其中旧代码依赖于不再是隐式运行时转换允许的。

因此,我可能不会批量更改您现有的项目。我可能会在很长一段时间内一次更改一个类/模块/文件,因为我不得不维护这些模块。我马上要做的就是开始进行单元测试。我觉得单元测试和静态类型检查在它们阻止的错误类型上有一些重要的重叠。单元测试对每个人都很有用,但如果你没有从编译器中获得类型检查的好处,那么它就特别重要。

这引出了我关于单元测试的更广泛的哲学:你应该进行单元测试,无论你是谁,至少进行回归测试(当你修复bug时,为它编写一个测试错误,以防止它在以后的编辑中重复出现)。如果您使用的是动态语言,并且带有Option Strict Off的VB计数,那么您还应该执行完整的测试驱动开发理念,在编写代码之前编写测试,并推动100%的代码覆盖率。相反,具有静态类型检查的语言允许编译器清除测试驱动开发用于防止的许多错误,因此您可以减少繁琐的测试编写(不是说您根本不应该进行测试,而是100%的代码覆盖率可能不是必需的,也不是测试优先的理念。)