Option Strict ON - WHY use it???

[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.

 

[Gerry O'Brien [MVP]]

There are likely many reasons why you should have OPTION STRICT ON all the
time.

My main reason for using it is to watch for narrowing conversions. Places
in code where I might inadvertanly perform a conversion from a double to a
single ore perhaps any floating point value to an integer value.

 

[Noozer]

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.

If you notice the different between having it ON or OFF, then you aren't
programming very well.

Turn it on and fix the errors.

 

[Cor Ligthert]

Clyde,

It is up to you, when you are programming in an access kind of way,
scripting way, you can use option strict of and let the computer do things
for you at run time.

This means directly that your program becomes more insecure and does not
have the performance as it could be.

A simple sample.
When you say
dim a as object
a = 1
dim 1 as integer = a
Than this goes with option strict of, however the program does now not know
what conversion should be done at run time and solves it at that moment.

With option strict on it has to be
dim 1 as integer = Cint(a) 'or any other casting, conversion, parsing
command and is it done at run time.

Before you say it, I myself find it strange that this is not build in
automaticly, because the compiler knows this at run time. He tells you that
you that Option Strict Disallows you to do an implicit conversion from
integer to object.

Therefore he can do that in my opinion in design time himself at least by
giving a default which can be choosen with one click. (Or with an option
which tells always to set the standard conversion function in this kind of
situations).

I hope this helps?

Cor

 

[Guest]

I believe using a lot of late binding will cause your program to run quite a
bit slower.

 

[W.G. Ryan eMVP]

It definitely will affect performance - not to mention it will greatly
increase the chances of making some hard to find logic errors.

 

[W.G. Ryan eMVP]

Amen!

 

[Cor Ligthert]

Bill,

It definitely will affect performance -

It does not.

Cor

 

[Herfried K. Wagner [MVP]]

It does not.

Huh?!

 

[Aaron Smith]

Huh?!

I don't know if it affects performance or not. But I do know this. I
turned it on in my application and now I have about 500 errors to fix!
Thanks alot people!

 

[W.G. Ryan eMVP]

Cor - not sure if you understood what I was saying or not. What I was
saying is that Option Strict On code runs much faster - by having it off
code will definitely run slower. If you wrote code with Option Strict Off
that was strongly typed and woudl compile with Option Strict On, that
difference would be minimized somewhat but it will still run slower. I
could go through the list of reasons why but I could never do it as well as
Dan Appleman did
http://www.desaware.com/products/books/net/exploring/index.aspx

 

[W.G. Ryan eMVP]

Aaron - trust me on this - Seriously - This is the best thing you've done
for yourself. Option Strict Off is bad in so many ways. Yes, it's a little
more of a pain getting used to On at first, but it's soooo worth it. You'll
get much better performance, catch potential bugs early and get the added
benefit of intellisense.

Take this beauty which I got from the DailyWTF - Friend ReadOnly Property
CheckUserRole() As Boolean
Get
Dim user As SystemUser = SystemUser.CurrentUser
If user.AssertRole(RoleTypes.Admin) Then
Return 0
Else
If user.AssertRole(RoleTypes.Training) Then
Return 1
Else
If user.AssertRole(RoleTypes.Supervisor) Then
Return 2
End If
End If
End If
End Get
End Property

http://msmvps.com/williamryan/archive/2004/12/11/23477.aspx

Here's a great quote that someone posted in response to this code:
Isn't it incredible how many run-time mysteries become compile-time wavy
underlines with circles and arrows and flashing lights and sound effects
when you use Option Explicit/Option Strict?

 

[Guest]

Aaron, I'm sure you realize those are necessairly errors, it's just that with
option strict on, you have to tell the compiler the type of the object before
you use it in code situations that requires knowing the object type in order
to execute.

 

[Aaron Smith]

I didn't even know much about Option Strict until I started to read
about after looking through this thread.

I used to do a lot of Visual C++ development a few years ago. An app can
run when there are warnings but no errors... Will it run good?
Probably.. Could it have a ton of bugs in it because there are warnings?
Yep. Then why not fix the warnings and prevent the bugs?

 

[Aaron Smith]

Aaron, I'm sure you realize those are necessairly errors, it's just that with
option strict on, you have to tell the compiler the type of the object before
you use it in code situations that requires knowing the object type in order
to execute.

Yea, but I would rather have it all correct.

 

[W.G. Ryan eMVP]

100% Agree with you.

 

[W.G. Ryan eMVP]

Or they may be things that will cause real errors - A prime example is what
I posted above:

CheckUserRole() As Boolean
Get
Dim user As SystemUser = SystemUser.CurrentUser
If user.AssertRole(RoleTypes.Admin) Then
Return 0
Else
If user.AssertRole(RoleTypes.Training) Then
Return 1
Else
If user.AssertRole(RoleTypes.Supervisor) Then
Return 2
End If
End If
End If
End Get
End Property

This is a Boolean function that can return 0, 1 or 2 - Very good chance what
you'll get back isn't what you expected. The problem is that they may or
may not be 'real' errors or cause 'real' errors - and you won't know until
runtime - better to catch it at design time - cheaper across the board.

Option Strict Off is an abomination and the few cases that it may be needed
notwithstanding (because they are very very few) it should be avoided like
the plague. Turning on Option Explicit may cause errors too - and they may
not be 'real' errors but they are surely bad and certainly capable of
causing problems you didn't expect and that you'll have to spend time
tracking down.

 

[Greg Burns]

Does the compiler directive itself affect performance? Or is just the
coding style it imposes that creates the performance boost?

In others words, if you wrote a program with Option Strict On and then
changed it to Off when finished, would it suddenly run slower???

Isn't the IL code the same?

Greg

 

[W.G. Ryan eMVP]

Greg - I believe the answer answer is yes. If you coded it exactly the same
you'd minimize the hit, but Option strict off generates late bound IL - but
mainly - the runtime doesn't have to do the same amount of checking. Let me
see if I can find the article I read on this...

 

[Greg Burns]

I just ordered a copy of Appleman's book. You perked my curiosity about the
Option Strict info inside.

Glad to see he did away with the security feature on the ebooks. My last
one from him I cannot even open anymore (dead login link). ;(

Greg