23

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

我想就是否建议他们始终启用Option Strict提出一些建议。

我专门使用 C 风格的编程语言，主要是 Java 和 C#，所以对我来说，显式转换是我一直希望我必须做的事情，因为它从来都不是一种选择。
但是，我认识到使用内置支持后期绑定的语言的价值，因为不必过于明确地说明代码中的类型确实可以节省时间。动态类型语言的流行传播进一步证明了这一点，甚至在具有动态语言运行时的 .NET 平台上。

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

4

8 回答 8

26

是的！Option Strict 绝对是 .Net 的最佳实践。强调 .Net 的核心是一个强类型平台，直到 DLR 得到更完全的支持。除了少数例外，每个DimandFunction都应该有一个明确的类型声明与之配套。像 LINQ 或 Boo 和 JScript 这样的东西是证明规则的例外。

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

  • 不要使用旧的字符串函数：LEN(), REPLACE(), TRIM(), 等等
  • 不再推荐匈牙利疣。 oMyObject并且sMyString不是犹太洁食。如果他们不相信您，请向他们展示Microsoft 设计指南中的参考资料。
  • 确保他们了解新的AndAlso/OrElse逻辑运算符
  • 参数化查询和现代 ADO.Net。怎么强调都不过分。他们永远不需要再打电话CreateObject()了。
  • Scope 在 .Net 中的工作方式与在 VB6 中的工作方式不同（并且更重要）。VB.Net 仍然有模块，但它们现在更类似于静态类。了解在真正的面向对象环境中开发与 VB6 提供的部分 OOP 支持有何不同非常重要。不再有充分的理由允许方法运行到不敬虔的程度。
  • 确保他们了解泛型和接口（包括IEnumeralbe(Of T)），并了解为什么他们永远不应该ArrayList再次使用 an。

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

于 2008-10-21T16:16:56.197 回答
18

使用 Option Strict 启用开发所花费的时间将为您节省大量的调试时间。

于 2008-10-21T15:54:41.420 回答
8

Option Strict显然不能取代好的单元测试——但反过来也不能。虽然单元测试可以检测到与 相同的错误Option Strict，但这意味着单元测试中没有错误，单元测试经常和早期完成，等等......。

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

总而言之，不能保证您的单元测试是正确的。另一方面，有一个强有力的保证，即编译器执行的类型检查是正确的，或者至少它的故障（未经检查的数组协方差、循环引用的错误……）是众所周知的并且有据可查。

另一个总结：是的，Option Strict On绝对是最佳实践。事实上，我已经在这样的在线社区工作了多年。每当有人在显然没有Option Strict启用的代码上需要帮助时，我们都会礼貌地指出这一点，并拒绝提供任何进一步的帮助，直到这个问题得到解决。它节省了很多时间。通常，在此之后问题就消失了。这有点类似于在 HTML 支持论坛中寻求帮助时使用正确的 HTML：无效的 HTML 可能会起作用，但话又说回来，它可能不起作用并且是问题的原因。因此，许多专业人士拒绝提供帮助。

于 2008-10-21T16:11:29.047 回答
5

是的！！！！

在我看来，无论是作为开发人员，还是作为大学讲师，都是的。

最好从一开始就养成良好的习惯，这会使整个过程变得更加容易，而 Option Strict 是我认为需要的元素之一。

添加

从字面上可以列出很多原因，但关键是这是一种最佳实践，在教授一门新语言时，从一开始就教授这些最佳实践是关键。

于 2008-10-21T15:56:04.477 回答
4

请记住，这里有两个级别。

选项显式选项严格

两者的主要区别在于 Option Strict 禁用了 VB 对不同数据类型的自动转换。您必须显式使用 CType 或其他数据转换函数将变量分配给其他类型。

我从 1.0 开始就一直在使用 VB，虽然我可以看到这一点，但我认为 Strict 在处理已经实现或继承了不同接口和类的对象时特别热心。

我会先从 Strict 开始，如果它开始妨碍你，然后下拉到 Explicit。但是永远不要同时关闭，那样会导致疯狂和过多的调试时间。

多年来使用 VB，我几乎将 Double 用于所有浮点变量。这样，您就可以避免许多与舍入和精度损失有关的问题。在 VB6 中，我使用 long 作为 32 位整数，但 Integer 在 .NET 中的工作与 Int32 一样好。我还建议使用 Int32、Int16 等而不是 Integer、Long 等，以防微软决定重新定义这些关键字。

于 2008-10-21T17:14:41.527 回答
3

我不同意RS Conley（非常不寻常）。我最喜欢的 VB6 大师——Francesco Balena、Dan Appleman——都不喜欢 VB6 的自动转换，而支持 .NETOption Strict。许多有经验的 VB6 程序员都知道自动转换是“邪恶的类型强制”（pdf），并且会很高兴打开Option Strict.

有时最好使用一个不带 的小模块Option Strict，以避免大量复杂的反射代码。但这是证明规则的例外。

于 2009-06-09T10:43:31.487 回答
2

鉴于 Boehm 的理念，即在开发周期的早期解决问题消耗的资源最少，我喜欢每一种帮助开发人员尽早“解决问题”的工具。出于这个原因，我提倡诸如 IntelliSense 之类的东西，它既可以提高效率，又可以帮助您在周期的早期实现工作代码。（工作，但不一定正确。）

出于这个原因，我也支持使用 Option Strict 作为一种帮助在“设计时间”中防止失误和随之而来的更正的方法。

于 2010-04-12T14:11:56.407 回答
0

如果您习惯于检查您的类型，那么您可能需要 option strict on。关闭它可能有好处，但如果你的大脑没有调整到发现编译器通常会抱怨的错误，那么我会说让它保持打开状态。我在 VB.Net 中工作过很多次，我不得不说，即使我大部分时间都使用严格关闭的选项，但我已经看到很多情况下，打开它会阻止很多错误。

于 2008-10-21T15:57:05.863 回答