您在项目中使用严格关闭吗？
您使用“严格关闭”选项、“显式关闭”吗？ 或者可能是“严格自定义”和一些其他选项，例如“隐式类型”。 假定对象”、“后期绑定”、“隐式转换”？
Do you use 'strict off' option, 'explicit off'? Or may be 'strict custom' and some other options like 'Implicit type. Object assumed', 'Late binding', 'Implicit conversion'?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
绝不。 OPTIONS STRICT OFF 与 OPTIONS BADPROGRAMMING ON 相同。
OPTIONS STRICT OFF 放宽了 VB.NET 进行的一些检查。 它放宽了语言规则。 这些规则的存在是为了拯救你自己。 永远不要阻止语言拯救你自己。 如果您来自更轻松的环境，则尤其如此，在这种情况下，您很可能需要储蓄。
另一件需要注意的事情是，大多数编程语言都没有一个开关来表示：请允许我搬起石头砸自己的脚。
Never. OPTIONS STRICT OFF is the same as OPTIONS BADPROGRAMMING ON.
OPTIONS STRICT OFF relaxes some of the checks that VB.NET makes. It relaxes language rules. Those rules are there to save you from yourself. Don't ever prevent the language from saving you from yourself. This is especially true if you're coming from a more releaxed environment, in which case chances are that you need saving.
Another thing to note is that most programming languages don't have a switch to say: please allow me to shoot myself in the foot.
始终使用任何语言进行开发，并带有完整的警告和限制。 从来没有例外。
否则就是一种错误的经济，当然它可能看起来有效，但肯定它稍后会回来咬你
（目前正在调试一系列 PHP Web 应用程序，其中原始的 ' coder' 抑制了所有错误，并且在启用时每页显示数百个错误。“确保在测试中使用变量之前定义变量？当我可以抑制错误而不必思考时，为什么我要这样做？ ”）
Always develop in any language with full warnings and restrictions on. No exceptions, ever.
To do otherwise is a false economy, sure it may seem to work, but sure as hell it'll come back to bite you later
(currently debugging a series of PHP web applications where the original 'coder' had suppressed all errors and which, literally, display several hundred errors per page when enabled. "Make sure variables are defined before using them in tests? Why would I do that when i can just suppress the error and not have to think?" )
一般来说，我在项目级别保留 Option Strict On，因为一般来说我需要严格的语义检查。 如果我确实想使用后期绑定，我将在文件级别关闭 Option Strict。
Generally I leave Option Strict On at the project level because in general I want strict semantic checking. In the cases where I do want to use late binding I will turn Option Strict Off at the file level.
我喜欢使用 Strict=On，所以我的代码在编译时失败，而不是在它上线时失败，而 Explicit=On 是因为在静态语言中，不声明变量会有点奇怪。
I like to use Strict=On, so my code fails at compile time rather than when it's gone live, and Explicit=On because in a static language it would be kind of weird not to declare your variables.
当我开始一个新项目或收到一个活动项目时，我总是打开“严格”，
我永远不会为关闭该项目的项目提供支持，永远
I always turn Strict ON when I start a new project or when I receive an active project
I will never provide support on a project with that OFF, ever
我两种方式都做到了。 始终戴着它。 当我做一些快速而肮脏的 vbscripts 时，我没有打开它，这花费了我的调试时间。 打开它，保持打开状态
I have done it both ways. Always have it on. I did not have it on when was doing some quick and dirty vbscripts and it cost me debugging time. Turn it on, keep it on
Option Strict Off和Option Explicit Off是生产代码中的错误经济。您将花费更多的时间来追踪奇怪的错误，而不是首先编写没有错误和警告的代码。 我的经历告诉我这一点。
唯一的例外是当我需要使用后期绑定时，在这种情况下我必须将其关闭。
Option Strict OffandOption Explicit Offare False Economies in production code.You will spend more time chasing strange bugs than it takes to write your code error and warning free in the first place. My experience has taught me this.
The only exceptions is when I need to use late binding in which case I have to switch it off.
如果我正在做一些快速而肮脏的原型或尖峰，我知道将来不必维护代码，那么我通常会
严格关闭。不过，“知道”这个词在这里很关键，如果有任何机会代码会迁移到您需要支持的内容，那么请设置
Strict ON并在错误回来咬您之前处理它们。I usually have
Strict OFFif I'm doing some quick-and-dirty prototype or spike where I know I won't have to maintain the code in future.The word "know" is key here though, if there's any chance the code will migrate into something you need to support then set
Strict ONand deal with any errors before they come back to bite you.