When creating a new VB project, Visual Studio will automatically put Option Strict Off.
What is Option Strict and why should it be on?
Having Option Strict[^] set to Off is VERY dangerous because it allows you to implicitly convert types to other types. Take, for example, the following code:
Dim numeric As Integer = "1"
Dim otherNumeric As Integer = "Hello"
The first assignment of a String to an Integer will succeed. The second will fail miserably... At run time! Because Option Strict is Off, Visual Studio will not give an error on these types of conversions. Option Strict On however DOES prevent this sort of thing. The only way the above code would pass when having Option Strict On is by explicitly casting, like follows:
Dim numeric As Integer = CType("1", Integer)
Dim otherNumeric As Integer = CType("Hello", Integer)
This will still generate an error at run time, but at least the programmer has been made very aware at design time that this case might go wrong! Having Option Strict Off is a sin punished by run time crashes during production while you are enjoying your weekend (not anymore!). If this ruined your weekend, you deserved it ;P
So how do you put Option Strict On? There are two methods. First, go to your Project Options and click the Compile tab. Here, you will see some ComboBoxes, one of them has the label "Option Strict:" above it. Make sure it's set to On. This will enable Option Strict for your entire project! This option can be set to On by default by going to your Visual Studio Options (accessed from your Menu -> Tools -> Options...). In your Options screen, find the 'Projects and Solutions' options. Open this and then select 'VB Defaults'. This will show you the default settings for, among others, Option Strict. Make sure it's On. Every newly created project will now have Option Strict On by default!
Another method is typing:
Option Strict On
above your code file. This is especially handy when you have legacy software and setting Option Strict On on Project level will cause thousands of errors. At least your new code can benefit from design time errors and explicit casting!
So why would you ever want to have Option Strict Off? Well, in VB6, the Strict Off behaviour was default, so it is kind of a backward compatibility thing. All sorts of typecasting are done in the background (but do affect performance, and as mentioned, might throw unexpected Exceptions).
Second, Strict Off can be handy when using late binding. Consider, for example, the following code:
Dim someThirdPartyTool As Object = GetSomeObject
someThirdPartyTool.DoSomething
This code is perfectly legal with Option Strict Off. In fact, you can call any 'non-existent' method on a variable of the type Object (also called late binding[^]). So imagine that GetSomeObject dynamically loads some third party tool in your application. What's worse, this third party tool has terrible versioning, backward compatibility and multiple versions cannot be installed side by side. GetSomeObject could simply load the version of the third party tool which just so happens to be installed on the current computer and return some Object which interacts with the third party tool. You can then call DoSomething on the returned Object even though DoSomething is NOT a method of Object (just make sure the method is supported by the third party tool). So the obvious upsides to this are that you do not even need to have the third party tool installed to write and compile this code (a customer calls and says they're having trouble with third party tool version 1, but you currently have version 2 installed which doesn't support that method anymore)! It will only throw Exceptions at run time when the tool is not found or the method is not supported. The obvious downside is that a minor spelling mistake will mess up your application good and you don't have type checking or intellisense. When writing this kind of code, make sure you have a detailed manual which has every object and method in the library described in great detail.
Even better, write a uniform Interface and create a different implementation for each version of the tool (more work, but strongly typed, intellisense is supported, design time errors, etc.).
Another use for Option Strict Off is when working with COM Objects. I will not go into this discussion here, because I have no experience with this, but here[^] is a small blog post that's worth reading. Notice how working with COM can be achieved with Strict On too.
So while I do not think Option Strict Off is the best method to deal with any of these kind of situations, it might have its uses in some environments (the one having to maintain your code will want to kill you though, speaking from experience here :)).
Some more reading:
Why is this an issue in VB specifically? It's on by default in C#. :)
And why am I posting this? Because I see lots of new code that does not have Option Strict On and will almost certainly result in run time errors. :((
Happy coding!
History
- 23rd February, 2012: Initial version
