Option Strict Off

[Rory Becker]

A wise man once said: "Never put off until runtime what you can fix at compile
time."

Actually I think he said it about 10 minutes before I started this post.

I am a firm believer, like the man in question, in "Option Strict On" by
default.

Actually I don't believe I have code where this is not the case.

However I never say never (well perhaps not never :)) and so I would like
to investigate the exceptions to the "Option Strict On" policy.

I would like to get the group's take on when it *is* useful to disable this
and go for "Option Strict Off"

2 parts to this....

1. What situations can you think of where "Option Strict Off" is best because
of clarity of code?
2. What situations can you think of where "Option Strict Off" is best because
the really is no other way to achieve theend result otherwise?

Thanks for any input.

--
Rory

[rowe_newsgroups]

Re: Option Strict Off

A wise man once said: "Never put off until runtime what you can fix at compile

time."

lol - I've never been called a wise man before - thanks for the
compliment!

2. What situations can you think of where "Option Strict Off" is best because
the really is no other way to achieve theend result otherwise?

Latebinding immediately comes to mind, but I think you can suppress
the error message using a method attribute. I'll have to investigate
this further (or hopefully someone else will do it for me and let us
know).

Another reason why a developer might turn off Option Strict is if they
had a class VB conversion project that needed to be completed ASAP.
While this could allow runtime errors to sneak in, it might be a
necessary evil to reach a deadline.

That's about all I can think of at the moment, hopefully others will
share their thoughts.

Thanks,

Seth Rowe

[Patrice]

Re: Option Strict Off

1. IMO none (if clarity doesn't mean shorter for you)

2. Easy late binding (I believe this can be done "explicitel y", never
checked this)

Also as this can be set on a file by file basis, even in the later case you
can still use "option strict on" for your project (and have "option strict
off" only for this particular file where you "need" it).
Not tried but you can even perhaps split a class using the partial keywords
to set apart what need option strict off and have the rest of the class
still use your project option strict on default...

---
Patrice

"Rory Becker" <RoryBecker@new sgroup.nospama écrit dans le message de news:
b0ac48a01af838c 9bf798f1254a0@m snews.microsoft .com...

>A wise man once said: "Never put off until runtime what you can fix at
>compile time."
>
Actually I think he said it about 10 minutes before I started this post.
I am a firm believer, like the man in question, in "Option Strict On" by
default.
>
Actually I don't believe I have code where this is not the case.
However I never say never (well perhaps not never :)) and so I would like
to investigate the exceptions to the "Option Strict On" policy.
>
I would like to get the group's take on when it *is* useful to disable
this and go for "Option Strict Off"
>
2 parts to this....
1. What situations can you think of where "Option Strict Off" is best
because of clarity of code?
2. What situations can you think of where "Option Strict Off" is best
because the really is no other way to achieve theend result otherwise?
>
Thanks for any input.
>
--
Rory
>
>

[Cor Ligthert[MVP]]

Re: Option Strict Off

Rory,

Option Strict off is very good when you are new to VB. Don't spent time with
things that are not direct about the language it self. When you are no more
a newbie it is of course forever on in your standard options and you set it
therefore even anymore in top of your program.

If you really can go on (this happens never to me), than you can always use
Option Strict Off in top of your program.

Just my idea,

Cor


"Rory Becker" <RoryBecker@new sgroup.nospamsc hreef in bericht
news:b0ac48a01a f838c9bf798f125 4a0@msnews.micr osoft.com...

>A wise man once said: "Never put off until runtime what you can fix at
>compile time."
>
Actually I think he said it about 10 minutes before I started this post.
I am a firm believer, like the man in question, in "Option Strict On" by
default.
>
Actually I don't believe I have code where this is not the case.
However I never say never (well perhaps not never :)) and so I would like
to investigate the exceptions to the "Option Strict On" policy.
>
I would like to get the group's take on when it *is* useful to disable
this and go for "Option Strict Off"
>
2 parts to this....
1. What situations can you think of where "Option Strict Off" is best
because of clarity of code?
2. What situations can you think of where "Option Strict Off" is best
because the really is no other way to achieve theend result otherwise?
>
Thanks for any input.
>
--
Rory
>
>

[Mike McIntyre]

Re: Option Strict Off

Here a few reasons:

1. A good time to use OPTION STRICT OFF is when converting legacy VB
applications to .NET.

This makes it quicker to get a complex legacy app up and running - and then,
over time, you can back fill until most of all of your code works under
OPTION STRICT ON.

2. Prototyping VB applications. With OPTION STRICT OFF you can whip up
prototypes very quickly.

3. Working with COM. For some COM operations, using OPTIONS STRICT ON will
mean creating a whole lot of extra code - just ask a C# programmer who tries
to work with COM and doesn't have the OPTION STRICT OFF option.

--
Mike

Mike McIntyre [MVP]

http://www.getdotnetcode.com

"Rory Becker" <RoryBecker@new sgroup.nospamwr ote in message
news:b0ac48a01a f838c9bf798f125 4a0@msnews.micr osoft.com...

>A wise man once said: "Never put off until runtime what you can fix at
>compile time."
>
Actually I think he said it about 10 minutes before I started this post.
I am a firm believer, like the man in question, in "Option Strict On" by
default.
>
Actually I don't believe I have code where this is not the case.
However I never say never (well perhaps not never :)) and so I would like
to investigate the exceptions to the "Option Strict On" policy.
>
I would like to get the group's take on when it *is* useful to disable
this and go for "Option Strict Off"
>
2 parts to this....
1. What situations can you think of where "Option Strict Off" is best
because of clarity of code?
2. What situations can you think of where "Option Strict Off" is best
because the really is no other way to achieve theend result otherwise?
>
Thanks for any input.
>
--
Rory
>
>

[Michael D. Ober]

Re: Option Strict Off

1. Never, even when porting VB 6 or VBA code. I use Option Strict On and
fix the type errors. I have had instances where VB 6 programs would crash
for no apparent reason simply because VB 6 was mis-casting a variable.

2. Late Binding would be the only time. In this case I would actually do
the late binding in a small source file with Option Strict Off and lots of
comments explaining the datatypes involved.

Mike.

"Mike McIntyre" <mikemc@getdotn etcode.comwrote in message
news:u1qD1Fi8HH A.5712@TK2MSFTN GP04.phx.gbl...

Here a few reasons:
>
1. A good time to use OPTION STRICT OFF is when converting legacy VB
applications to .NET.
>
This makes it quicker to get a complex legacy app up and running - and
then, over time, you can back fill until most of all of your code works
under OPTION STRICT ON.
>
2. Prototyping VB applications. With OPTION STRICT OFF you can whip up
prototypes very quickly.
>
3. Working with COM. For some COM operations, using OPTIONS STRICT ON
will mean creating a whole lot of extra code - just ask a C# programmer
who tries to work with COM and doesn't have the OPTION STRICT OFF option.
>
--
Mike
>
Mike McIntyre [MVP]

http://www.getdotnetcode.com

>
>
"Rory Becker" <RoryBecker@new sgroup.nospamwr ote in message
news:b0ac48a01a f838c9bf798f125 4a0@msnews.micr osoft.com...

>>A wise man once said: "Never put off until runtime what you can fix at
>>compile time."
>>
>Actually I think he said it about 10 minutes before I started this post.
>I am a firm believer, like the man in question, in "Option Strict On" by
>default.
>>
>Actually I don't believe I have code where this is not the case.
>However I never say never (well perhaps not never :)) and so I would like
>to investigate the exceptions to the "Option Strict On" policy.
>>
>I would like to get the group's take on when it *is* useful to disable
>this and go for "Option Strict Off"
>>
>2 parts to this....
>1. What situations can you think of where "Option Strict Off" is best
>because of clarity of code?
>2. What situations can you think of where "Option Strict Off" is best
>because the really is no other way to achieve theend result otherwise?
>>
>Thanks for any input.
>>
>--
>Rory
>>
>>

>
>
>

[Jeffrey Tan[MSFT]]

RE: Option Strict Off

Hi Rory,

Have you reviewed all the community replies to you? Do they make sense to
you? If you still need any help or have any concern, please feel free to
feedback, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to

http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif

ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.

[Rory Becker]

RE: Option Strict Off

Jeffrey Tan wrote:

>
Have you reviewed all the community replies to you? Do they make sense
to you? If you still need any help or have any concern, please feel
free to feedback, thanks.

Apologies to all. I have been rather busy and have not, until now, found
time to reply

Yes I have read all replies and have found useful information in each.

My conclusion is that there is no valid use (for my purposes) of "Option
Strict Off" which can justify the loss of the extra checks provided by "Option
Strict On"

Hopefully thre answers provided will help others determine if this is the
case in their own scenarios

This has been a useful exercise in checking my own assumptions

My thanks once again to all.
--
Rory

[Jeffrey Tan[MSFT]]

RE: Option Strict Off

Hi Rory,

Thank you for the confirmation.

Yes, I agree turning on Option Strict should be good for most VB.net
programming. It will help us to find out programming errors at compile-time
instead of delaying to the runtime. This will improve our development
efficiency a lot.

Anyway, if you need further help, please feel free to post, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to

http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif

ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.