Rant - Option Strict Off

Published 29 December 4 11:57 PM | William

Today someone posted an innocent enough question in the VB.NET Newsgroup.  He was new to VB.NET and had turned on Option Strict - he immediately got over 500 errors.  He asked specifically why he should Option Strict.  I don't think any readers here don't already know the answer to this so I won't belabor the point. 

The interesting thing was that after reading the responses, the guy immediately made the decision to use Option Strict.  This in light of the fact that a few people downplayed its significance.  The poster made the point that he'd prefer to fix the problems up front. 

When the poster asked the question, he was 'ignorant' in an innocent sense of the word.  He was new to VB.NET and just didn't know.  But he was curious enough to ask and upon finding out why, he immediately saw the light and changed his way of doing things.  This, despite the fact that it was going to cause him to do quite a bit of work in the short run.  He had the foresight to see that it was going to save him work in the long run.

What I don't understand though - is people that have read the reasons and still opt to not use it (the extremely rare cases where Late binding is necessary notwithstanding- because even in those cases you can use it for everything else).

Somebody - please somebody - some VB6 know it all that refuses to change his/her ways- please explain to me what value Option Strict Off has FROM THE CUSTOMER'S point of view?  I've heard the “I can write code faster without it” but I don't buy that for one second.  I can write code really really fast too if it doesn't have to work correctly.  So what?  I've never gotten paid to write stuff that doesn't work.  People will tolerate mistakes and consequently know that some bugs will exist, but no one has ever said “Bill, I need this ASAP, I don't care how many bugs it has and I don't care if it doesn't meet my needs”  Well, that's the implicit assumption of turning off Option Strict to speed up development.  Why?  Because you are almost guaranteed to make some mistakes that would be caught otherwise.  And even if you think you're such a bad a33 that you won't, you'll at least have to manually check over everything thoroughly to ensure that you didn't.  That takes TIME.  Time that would have been saved if the compiler caught it on the front end.

But most importantly, Design time mistakes are practically FREE when compared with mistakes found after the application is in the customer's hands.  Let's say that on average, I make 40 mistakes a day that the compiler catches - from forgetting a return type, or not having all paths return a value to whatever else including typos.  My boss wouldn't care one bit.  People make small mistakes all the time.  But if 1 bug a day on average was found in code that I wrote that was deployed- I wouldn't have a job anywhere but Smith Data Processing or the government (just kidding).  That's because <gasp>  Design time mistakes are easy and quick to fix - deployment ones aren't.

So if we arbitrarily cutoff the time frame to include just today - then yes, I guess you could code slightly faster.  But the time frame doesn't end until the customer stops using that version of your product.  So if you do it quicker today but have to fix it later, you didn't save time or money - you actually ended up costing time and money. 

VB.NET is a VAST Improvement over VB6 - and although you can write good code in VB6 - it's easy to write bad code.  No one in their right mind (or that has the first clue what they are talking about will debate this).  But can you write good code in VB6 with say Option Explicit Off?  Have fun - b/c unless you never make typos chances are you are going to get some whacky results.  Why fight the improvements?  What possible benefit does it provide if you Know the 'right' way to do things but ignore it?  It sure as hell doesn't benefit the customer. 

------------

Someone actually posted that Option Strict On doesn't help performance.  You have to be ******** kidding me.  And this comment came from someone who has been in many such debates and has supposedly read why Off is a bad thing.  Look, I don't care what the Option is, if I turn it on and every goddamned program I wrote won't compile with it - something is wrong.   But unless the Option is totally throwing false alarms, why not flip the thing on and at least verify that it's not blowing smoke? 

This is the second type of ignorance, and it's inexcusable.  Look, old boy in the newsgroups was new to VB.NET.  There's a learning curve.  You are necessarily going to be ignorant when you first learn something. And like a real professional, he inquired about it and took corrective action on it.  But people that have been using something for a while, and have done the inquiry and chosen to ignore it - presumably because they know better than everyone else in the gd world, that's so pathetic it's hard to really describe.  We all have a bad habit or two that we refuse to give up - but as professionals those should certainly be few and far between - and we should correct them to the extent that we are the only ones hurt by them.  But this BS attitude of “I've been a programmer for x years and I know better.”  Really?  What in the hell does being a VB5,6 programmer for 5 years really mean when you are in .NET and haven't learned it yet?  Not much.  What in the hell does that mean when you refuse to accomodate the new changes?  Does programming VB6 for even 100 years cause your bugs to not be bugs in .NET or whatever other new environment you are working in?  I'm the first to admit that experience matters a whole lot - but that's ONLY IF YOU LEARN from that experience.  If you make mistakes and are too proud or egotisitical to acknowledge that you made a mistake - and therefore refuse to take corrective action - what good is that experience?  If you still make the same rookie mistakes over and over after working with something for a few years, all that means is you're either pigheaded or stupid - probably some of both. 

It's just too bad that we can't take all of the Option Strict Off, Non-Paramaterized Dynamic SQL Writing, Refusing to use a Stringbuilder, On Error Resume next advocates and stick them in one company so it could go out of business and they could move on to Amway sales or whatever.

----

And the most ironic part of the whole thing is that the dude that was saying it doesn't impact performance is a newsgroup regular.  And on three occassions he's started complaining whenever other people got the MVP award and he didn't.  Spare me the conspiracy theories old boy because with viewpoints like this - you're your own worst enemy.

Comments

# William said on December 30, 2004 12:51 AM:

For the record, my late binding issue was VB6 related, not Vb.Net. See blog for update.

On to this...I don't get it. I don't use VB.Net as a rule (well, at all actually) but I am aware of option strict. Why you would not want to use it is beyond me.

If someone actually ever says to you in person that he can code faster with it off...please slap the shit out of him. I can type really fast if it doesn't have to do anything...observe:

asl;dkfuxmdkdfuem iadnaksdfj isvnaksdf i aksdfj

Yeah...that took like a second. But it doesn't work. it's full of bugs, and the time I supposedly saved by having option strict off at design time is probably inversely proportional to the time i will spend debugging the damn thing at runtime.

Then again, these are the same people that never used Option Explicit in VB6, (which was the only thing standing between you and stupid typo bugs, because the compiler let you do anything you wanted pretty much) because they had to dim all their variables and that took too long.

# William said on December 30, 2004 1:13 AM:

Sorry about that on the first count ;-).

Dude - I'm sooo with you on the rest of your comments. Who cares about fast and buggy - that always equals sucks a33. And boy o boy are the customers going to be glad you did it sooo quickly and they only have to sit around for 8 hours while you fix it for them.

The only good thing about it is that it's amusing to listen to the bullsh1t , I mean reasons, folks like this cite for why they insist on doing things the WRONG freaking way.

# William said on December 30, 2004 2:32 AM:

it's a typical case of i'm-stuck-in-my-path-and-cannot-find-my-brain scenario which leaves you with shite excuses for continueing to do stupid arse things even after having been told it's WRONG.

most devheads dont like to admit they do something the wrong way and can usually come up with 6.000.000 colourfull excuses as to why they do things the way they do - but a good developer will see reason and adjust.

i'm by far a perfect code guru and do things (sometimes) that might not make much sense to somebody far more experienced but at least i try to work the right way once i see the light. hell i'm sure if you guys picked through some of my code you'd shake your head, but at least i'd pull my head out of my arse to get it right after you'd stuck an icepick through my ear for being a moron!

# William said on December 30, 2004 3:00 AM:

Okay, here's a twist .. suggest me situations where you would WANT TO leave Option Strict Off??

# William said on December 30, 2004 6:08 AM:

Bill you've hit the nail on the head. I get so pissed off with people leaving option strict off or even discussing it *but* I get more pissed off with MSFT making the default OFF, WTF?! I understand the upgrading of VB6 projects requiring the option off but don't make it the £$%^ing default for new projects! I know you can edit the templates to change the behaviour but that is not good enough. Even in MSFT sample code (even with VS2005) they leave the option OFF!! Anyway... Thanks for the post; I will now link to this whenever someone attempts to engage in conversation on the topic. It is my number one rule for VB.NET coders:
http://www.danielmoth.com/Blog/2004/09/vb-rules-net-way.html

And by the way, the only valid argument for leaving the option off is *extremely* easy late binding. But I would not defend that for any code that has to leave your PC and run on somebody else's!

# William said on December 30, 2004 6:45 AM:

Great post, Bill.

Sahil, the ONLY case where it makes sense is when you have developed code accepts Objects as parameters, and needs to test them to see if they expose certain properties and methods.

When you do so, you should isolate the offensive code in its own file with Option Explicit (Off? No way).

The need for this type of code arises in two places.

You may be writing a reusable utility or tool to do something for a wide class of objects. For example (but in VB-6), I recently wrote a tool for a group at my company which accepted any Object or non-object Variant and returned a serialized character dump of the Variant.

Numbers were displayed as in Integer(5). Strings were quoted such that internal quotes were doubled as in String("""") for a quote. Non-ASCII and control characters transformed strings into expressions as in String(ChrW(13) & ChrW(10)).

Objects inside the variant passed were where VB-6 weak typing was useful, and the analogue would be code isolated in its own module with Option Explicit.

This is because the serializer needed to "empirically" determine whether the Object in the Variant had a Name, using weak binding, or was a collection or collection-like thing.

The use of weak binding was isolated to only a couple of lines in the code.

Another situation arises in software research and maintenance where a sloppy system written using Option Explicit in .Net, or UNNECESSARY weak binding, is passing things As Object or As Variant with unpredictable contents.

You can add code to unsnarl the mess that tests the objects for their characteristics using weak binding or isolation in small Option Explicit modules.

In both cases, you are using VB 6 and VB.Net in an unfamiliar way, and that is for self-reflexive tool building.


One downside of strong typing is that it can force duplication of code when the object designers haven't factored properly, and objects share properties and methods.

Here, the defect is in the language. When I get around to designing and implementing an OO language, Properties of objects (and methods) will be "first class objects" fully visible both in themselves and in a list associated with the object.

This means that it will in my language be possible to compare "apples and oranges" and determine their relationship at run time.

objType1 Is Like objType2 under constraints if they share an intersection set of properties of the same (or similar, using Like logic) properties.

All this is already doable with some really nasty CLR coding but it should be at the level of the object.

Implementation details would be extremely grotty but ALREADY the CLR is loaded far more than traditional runtimes with structural and type information.

Objects, in other words, need to be fully self-aware. My objects are ALREADY racked with guilt since I consistently implement an inspect() method and a test() method for stateful and significant objects which inspect state and self-test. I want them to become truly free beings who can meditate at run time on their structure.

Which runs counter to the management ideal of "simplicity", of course, but the fun thing about having a laptop is you can dream.


None of this should be interpreted as any sort of case for the usual practice which is to turn Option Off on and hope that the code works.

# William said on December 30, 2004 6:51 AM:

My examples are of course arcane. I write tools in VB all the time where other programmers would use C++ or find a third party tool because my experience in languages prior to VB was of the power of microfactoring beyond what the user wants or sees. I was under contract to write a tools book for Addison Wesley, but they canceled it when they decided to cut back on VB books.

But I would make the case that it MIGHT make sense in ordinary programming to isolate a few lines of code in an Option Explicit module. One situation is where two classes expose the same property using the same type, and you need to write complex code to handle the property value.

Duplicating the code means that changes to the one have to be replicated in the other and this is a MAJOR programming offence in my view.

# William said on December 30, 2004 10:10 AM:

http://msmvps.com/bill/archive/2004/12/31/28480.aspx

# William said on December 30, 2004 10:54 AM:

Sahil:

I would think that when you are doing a VB6 port it's necessary - but you can take it away one class at a time.

# William said on December 30, 2004 10:59 AM:

Edward :

Thanks for the comments. I guess my entire point is that Option Strict off is like Herion in some ways. If I'm in real pain - it'll work in a pinch (not that I'd know personally). However it's easy to get addicted to the stuff and before you know it you're hooked. THe same with using Goto or Option Strict or a whole host of other things. Used once or twice in isolation by people that understand the consequences and make informed decisions - none of it's a big deal. But by and large - you seldom see code with just one Goto - it creeps. Then before you know it it becomes a default solution. Same for Option Strict. Most folks leave it off totally - it's not just turned off on a given class or module.

If I had a dollar for each newsgroup problem I've seen that was directly attributable to not having Option Strict On, I'd be sipping Remy Martin in my Jet right now heading over to China to get some of those fart bombs - and then hopefully setting of some cool fireworks with you ;-)

# William said on December 30, 2004 4:40 PM:

Okay in addition to VB6 ports, here is another situation. A lot of Win32 functions expect nullable value types.

Anyway, I whole heartedly agree that Option Strict is your friend.

# William said on December 30, 2004 4:44 PM:

Sahil:

Check your blog on the MVC post - then drop me an email if you have a second - not a big deal - just want to ask you something...

# William said on December 30, 2004 6:36 PM:

Hi Bill,

Tell us what you really think :-)

Couldn't agree more. The ironic part is that people describe leaving Option Strict Off as a thing for beginners. I see it as an advanced technique only !

Regards,

Greg

# William said on December 30, 2004 6:43 PM:

The sad thing is that Beginners usually Get it once you tell them why it's that way - it's always 'know it alls' that are too smart to use it.

# William said on December 30, 2004 8:42 PM:

that's right Bill....or correctly termed "Know-nothing-at-alls" instead??

Search

This Blog

Tags

Community

Archives

News

  • William G Ryan William Ryan Bill Ryan W.G. Ryan Charles Mark Carroll Charles M Carroll
    My Blog Juice Microsoft MVP
    Bill Ryan W.G. Ryan William Ryan
    Cuckooz' MySpace Page View Bill Ryan's profile on LinkedIn
    My Profile on Twitter
    Please note that this is my personal blog and the opinions expressed are my own. Also, comment moderation is about one of the least important things in my life so please keep that in mind. I can't vouch for the authenticity of any of the posters so please don't hold me accountable. And whatever you do, don't pretend to be Noted Option Strict Off expert and AspFriend Charles Mark Carroll when you post. Doing so will lead him to become apoplectic and write absurd accusatory posts about me that are as coherent and thought out as they are factually correct. He does a stellar job proving his reputation is well deserved and he doesn't need any help from you making himself look foolish. If I have to listen to him banging his spoon off of his high chair one more time, I'm going to burst into flames so please don't make that happen!

    My other sites

    Cool Stuff

    Book Stuff

    Security

    ORM

    Data Access

    Funny Stuff

    Compact Framework Stuff

    Web Casts

    My KnowledgeBase Articles

    My MVP Profile

    Design Patterns

    Performance

    Debugging

    Remoting

    My Fellow Authors

    My Books

    LINQ

    Misc

    Speech

    Syndication

    Email Notifications