Why you MUST use Option Explicit... er, Strict

I'm not all that against VB.NET, but I'll be honest -- I normally cringe when going to a client site that uses it exclusively.  The reasons are many and varied, but most of the time my fears are groundless... But one thing that gives me night terrors is seeing VB.NET projects with Option Strict not turned on.

Back in the days of VB6, those people wishing to write second-rate and error-prone code had the nifty switch called “Option Explicit” - To simplify it, we'll say it's a compiler switch that said “Error the compile if variables aren't explicitly declared before use”.   It stopped you from saying Dim Abcde as Integer on one line, and DoSomething(Abce) on another.  I can't tell you the number of times I'd get handed code, turn Option Explicit on in a file and immediately have the build break.  Yikes!  Never once was there an acceptable reason to do this. (One person did start in on performance nit-picks - don't let me get started).

The best part was that the great (no sarcasm, VB6 was, and a great tool for many purposes) people who brought us VB6 turned the option off by default for what I imagine was compatibility reasons.  So most people never turned it on, and many of them turned out poor-quality code (I don't know what's cause and what's effect here, did great developers turn it on, or did turning it on make developers great? My bet is more the latter than the former, but I'm sure it helped to catch errors at compile-time)

Now we have Option Strict ( I don't need to explain all of what it does, this is the web - I link ) Which restricts implicit type conversions.  It also verifies that functions have return types and all paths return a value -- all things that that the C# compiler always verifies.  It's a performance helper(by elimitating hidden type conversions), catches lots of possible errors, and is generally a must... but again, it's off by default (AAARGH!).  I'm sure the reasons for that are many and good, but.... AAARGH.

Why is it a must?  Well, I've been fixing lots of code, and here's something I must have fixed four times, just this week - a bug that can be very subtle and hard to track down without Option Strict.

Public Function Something(Arg1 as AnEnumType) As SomeObject
   Select Case Arg1
      Case AnEnumType.A
          Return New SomeObject(1)
      Case AnEnumType.B
          Return New SomeObject(2)
      Case AnEnumType.B
          Return New SomeObject(3)
   End Select
End Function

Why is this bad? Well, what if I add a new enum to AnEnumType, say AnEnumTypeD... what gets returned? Nothing, that's what.  And when you just know that a code path has to return an object this can be fun to track down.  There are lots of other cases where this happens, involving catch blocks that don't rethrow but cause the return to be skipped, If's with no Else's, and so on, but they're all bad.

So please, code with Option Strict on -- if you start with it off, it can be hell to go “strict-ify” your code later.  Us poor slobs who have to add features later will sure appreciate it.


  • I am responsible for adding some ASP code to an ASP site that cannot be run with Option Explicit. My new pages must include some existing include files. The client does not want changes to the site outside of my pages, so because the original vendor did not use Option Explicit (nor, most of the time, declare variables) I am stuck unable to use Option Explicit. People who do not use Option Explicit and Strinct in VB.NET should be kept away from computers...

  • There -- that's the only reason not to use it. Because some yahoo didn't and you're stuck without the time to redo what they did.

    And I agree - far, far away. They can go code for my competitors.

  • Eh... there are some situations where strict typing is more trouble than it's worth. I wouldn't turn Option Strict off for a project, but for a file where I was doing a lot of late binding, VB.NET with Option Strict off is a lot less painful than fooling around with reflection.

  • Agree with Doug, Philip and especially Dave. It would be cool however if you could define this behavior not on a source-file level but instead in a block as in

    Public Sub Foo()

    Dim X As Object

    Option Strict Off



    End Option

    End Sub

  • And for the sample given, even though you test for an enum, you should use an Case Else to catch unknown values if you change the Enum later in the project.

  • Asbjorn: Yes you SHOULD do that... but as I said, I'm fixing the code. Option Strict would force you to put in the Case Else, but leaving it off allows that.

    Dave, Ingo: I do agree with you, and I do turn it off in some files just for that reason... but it's a concious decision to turn it off. I think the vast majority of vb.net applications with Option Strict off have it off because of ignorance or laziness - only a small percentage have it turned of because of late binding.

    Perhaps once again I lay out an absolute rule a bit to absolutely? To be honest though, I'd rather have to work around it and have it be on all the time with no option than to have it be off all the time with no option.

  • I liked reading your article here, however I have a question for you, and what you think I should do.

    And yes, I know these comments were based 4.5 years ago.

    I have created a file, a huge file, that allows me to do quick coding, but mostly in late binding. I can run a huge registration section in 16 lines of code and validation.

    However, option strict does not allow late binding, therefore my file fails.

    Is there a way around it to allow option strict on EXCEPT for late binding? Thanks.


  • If you want to turn on Option Strict that's your prerogative. But if all you want is to make sure all functions return on all paths then just change "Function/Operator without return value" to a warning or error. No need to get Option Strict involved.

    And Michael, you can change Option Strict on a file bases per file instead of for the whole project by placing "Option Strict On" or "Option Strict Off" at the top of the file. In your case you would have to move the relevant code into a new file though.

  • I agree with Nick Avery's previous comment with the following additions.

    Work with as many of the "Warning Configurations" set to "Error" ow "Warning" as possible at the global level. Start with them all set to "Error". Or turn them on one by one and clean code as you can.

    The only one that can be extreamly labour intensive to code against in every case is "Late Binding, Could fail at runtime", which is the only one I have frequently left supressed in code (though I do everything I can to keep it set as well)

    One other thing to mention, the Author is fairly open minded about "I'm not all that against VB.NET, but I'll be honest -- I normally cringe when going to a client site that uses it exclusively.".
    Most developers who are not VB based for some reason detest VB, I suspect the main reason is the general lack of use of these options. When all these options are ON, VB is as type safe as C#.

    At one point one of our main developers left, who was a C# advocate. After he left we (I mainly) converted all the C# code to VB to allow better marshalling of "Best Coding Practises", and the most interesting learning point of the exercise was that this developer had produced huge ammounts of unsafe and sloppy C# code that was discovered and fixed during this migration.

    The point of that statement is not to advocate a language but to show the point that regardless of which language is in use the quality of the code is really down to the developers and how there using the system.

Comments have been disabled for this content.