Option Strict ON - WHY use it??

  • Thread starter Thread starter Microsoft News
  • Start date Start date
M

Microsoft News

I have a project that was created all with Option Strict OFF. Works great,
not a problem with it. But if I turn Option Strict ON then I get a LOT of
errors.

My question, should I even care about Option Strict?
What advantages do I get with Option Strict On?
Does better type statement make my code run faster?

If anyone knows THE ANSWERS! please fill me in. I have ideas and belief but
I would once and for all like to know what the difference is.

Thank in advance

Clyde W.
 
Answers inline

Microsoft News said:
I have a project that was created all with Option Strict OFF. Works great,
not a problem with it. But if I turn Option Strict ON then I get a LOT of
errors.

My question, should I even care about Option Strict?

Becaue you don't like sloppy code.
What advantages do I get with Option Strict On?

The primary one is forcing explicit coding standards.
Does better type statement make my code run faster?

NO. But, Option Strict can get rid of some really annoying logic errors
(syntax errors blow up, logic errors introduce bad data to application,
possibly even messing up your database).

OK, I will take that back. There are times when Option Strict can improve
performance, as well, by taking away certain VB.NET crutches.
If anyone knows THE ANSWERS! please fill me in. I have ideas and belief but
I would once and for all like to know what the difference is.

Overall, explicit coding is better, both for maintenance and ensuring your
code runs as expected. In 90% + of scenarios, turing Option Strict OFF is
fine. It is that small percent where it kills you. In most cases, bad
programming practice causes code to blow up when you turn Option Strict ON.
It is better to conquer those potential problems than leave them and turn it
back OFF. This is much like treating WARNINGS as ERRORS. While code works
fine when they are there, there is a small percentage of code that either
bombs, or worse, corrupts data when WARNINGS are left in. Best to erradicate
than take chances. Just my two cents.


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
With said:
It is better to conquer those potential problems than leave them and turn it
back OFF. This is much like treating WARNINGS as ERRORS. While code works
fine when they are there, there is a small percentage of code that either
bombs, or worse, corrupts data when WARNINGS are left in. Best to erradicate
than take chances. Just my two cents.

Interesting... I've too have always wondered about it. But my question (which
really doesn't need to be answered) is "why then NOT have it as a 'default' ON
and force all of us to clean UP our code?

If we "had" to write better code, then we would... but if we are not 'forced'
to... we write 'just to get by' code (and I am horribly guilty of that) (:

Regards,

Bruce
 
Kelly,

You have more answers including mine in the dotnet language.vb newsgroup.

Please do not multipost.

Cor
 
Bruce,

Probably it is not by default "on" because of the large part of VB6
programmers which are migrating, who will probably become crazy when they
have to do the casting as well.

I have it by default "on" in the Options and have seen not one situation
where I have to set it to "of".

However it is easier trying with option strict of, because sometimes you
have to cast more times with option strict on. (By instance when you are
trying something with MSHTML you can better start doing it with option
strict of and set the casting than later and put option strict on)

Just my thought,

Cor
 
Cor Ligthert said:
I have it by default "on" in the Options and have seen not one situation
where I have to set it to "of".

Huh! I didn't even see that in Options! I'll go look (kind of thought it was
funny that you couldn't see it one way or the other).
have to cast more times with option strict on. (By instance when you are
trying something with MSHTML you can better start doing it with option
strict of and set the casting than later and put option strict on)

Thanks Cor!

Bruce
 
Microsoft News said:
I have a project that was created all with Option Strict OFF. Works great,
not a problem with it. But if I turn Option Strict ON then I get a LOT of
errors.

My question, should I even care about Option Strict?
What advantages do I get with Option Strict On?
Does better type statement make my code run faster?

If anyone knows THE ANSWERS! please fill me in. I have ideas and belief but
I would once and for all like to know what the difference is.

Thank in advance

Clyde W.
This is from the .net sdk

Visual Basic .NET generally allows implicit conversions of any data type to
any other data type. Data loss can occur when the value of one data type is
converted to a data type with less precision or smaller capacity, however, a
run-time error message will occur if data will be lost in such a conversion.
Option Strict ensures compile-time notification of these types of
conversions so they may be avoided.

Mike
 
It should be on by default - that's one of the main things that people take
pot shots at VB.NET about
 
The fact that you 'get all these errors' tells you that your code has
issues. Go check out the DailyWTF for proof. Almost all of the REALLY bad
VB.NET code can only be as bad as it is b/c Option Strict is off

Your code will run a lot faster with Option Strict on and you'll have a
safety net to protect you from a lot of really bad but easy to make
mistakes.

Moreoever by using strong typing - you get intellisense support.

Option Strict Off = Option Slow ON!
 
Greg:

Not trying to nitpick but There's a big performance issue with leaving
option strict off.

As Dan Appleman has pointed out - Option Strict Off = Option Slow On.
 
Back
Top