August 4, 2005
I just noticed that Option Explicit is on by default for new VB solutions in Visual Studio .NET 2005:
It's about damn time.
There's nothing more vicious than making an innocent typo when referencing a variable and not knowing about it because the compiler silently declares a new variable for you:
MyStringName = "Pack my box with five dozen liquor jugs"
Just talking about it makes my eye twitch uncontrollably. It's almost as bad as making a language case sensitive.
Option Explicit Off is pure, unmitigated evil, yet Option Explicit Off is the default in VS.NET 2002 and 2003. I've audited a half-dozen VB.NET projects where, months into development, the developers didn't realize that it was off! Laugh all you want, but this is the power of default values.
Paul Vick pointed out that VS.NET 2002 and later do in fact ship with Option Explicit On set by default. What I really needed was an option not to work with knuckleheads who turn it off, because I got bitten with this one a few times.
I'm not sure that Option Strict is quite the no-brainer that Option Explicit is, but Dan Appleman sure has strong feelings about it:
One of the debates that has arisen with the arrival of Visual Basic .NET is the use of Option Strict. Option Strict turns on strong type checking. You've probably heard about "evil type coercion" (pdf) in Visual Basic 6 -- VB6's habit of converting data types automatically based on its best guess of what you want to do. While this can be a convenience to programmers, it can also lead to obscure and unexpected bugs when VB's guess does not correspond to what you intended.
The incorporation of strict type checking into Visual Basic .NET represents one of the most important improvements to the language. Unfortunately, Microsoft showed a stunning lack of confidence in their decision to incorporate it by leaving Option Strict off by default. In other words, when you create a new VB.NET project, strict type checking remains off.
Some argue that this is a good thing. Leaving Option Strict off allows VB.NET to automatically convert data types in the same way as VB6. Not only that, but with strict type checking off, VB.NET can automatically perform late binding on Object variables in the same way as VB6 (where a variable is of type "Object', VB will perform a late bound call on the object, correctly calling the requested method if it exists).
The people who make these arguments are wrong.
You should ALWAYS turn Option Strict On for every application.
He also calls this Option Slow, referring to the slow, expensive IL that must be emitted behind the scenes for this magical type conversion scheme to work-- the source of endless "VB.NET is slower than C#" benchmarks.
I tend to agree that this probably shouldn't be off by default, but it's nowhere near as poisonous as Option Explicit. Option Explicit Off has no legitimate use. Option Strict Off has one clear use case: it's great when you're writing a lot of late binding code. Let the IL deal with all the nasty, verbose type conversions. As Scott points out, we can now use partial classes in VB.NET 2.0 to mark selected sections of code Option Strict Off while leaving the rest Option Strict On. It's the best of both worlds.
I guess I could be critical of Microsoft for not having the balls to also turn Option Strict on by default, but I consider it a minor miracle that we even got Explicit. I'll take it.
Posted by Jeff Atwood
Option Explicit Off has been the default in the product since VS 2002. I'm not sure how the people you work with have managed to turn it off, but I can ASSURE you that we've shipped it with it off, for exactly the reason you state - it was too easy for misspellings to create new variables.
Er-- you're right. How did they manage to turn it off? I don't know why I work(ed) with such knuckleheads. Let me update the post to reflect the correction.
Indeed, Explicit On is the default:
My current clean install of VS.NET 2003 doesn't contain either Explicit or Strict, so it's fully default (not specified), and Explicit is definitely enforced.
I'm pretty sure now I was thinking of Option Strict the whole time, which is not on by default. Mea culpa.
I agree with Mr. Appleman, strict should be on as well.
No problem... As for the Option Strict thing, yeah, well, that's something we get a lot of feedback on. We'll just have to see... :-)
If people want the stricter option, why don't they just go for C#?
VB will always make a poor static language in my opinion. Keep its strengts, keep it dynamic, but make the dynamics both safer and faster.
Well.. considering the BCL TryParse sample I posted about today (granted, it's from Oct 2003) had a static bug in it*, I'm inclined to think it should be on by default.
It's definitely USEFUL, but I think having it on all the time is a mistake. It should be turned off as necessary for interop and other situations that warrant its use (or if the developer prefers it).
Couldn't this be done rather simply with project templates? Kind of like how VS.NET 2005 makes you select a development profile at install time (general, web, C#, etc). You could select "VB-loose" or "VB-strict".
* The DoubleTryParseRoutine and DoubleParseRoutine methods used "Double" and "Decimal" datatypes instead of Double/Double! Clearly an intellisense error, but it wasn't picked up because option strict was off..
Keep in mind the whole families of Python-like languages in which assignment is declaration and all typing is dynamic (everything's Var) - and tons of useful apps have been made in these languages.
It takes practice to be that careful, but you can create much less verbose, more legible code if you do - plus it's faster for quick one-offs.
Each approach has their place. Obviously if we're talking about some rigorous financial enterprise application, all safety should be maximized - heck, even typecasts should be avoided in that sort of environment.
I like option strict off even if the compiler tries to guess. It will do it only once and if you are smart you will learn its habits. As a seasoned programmer, I coded well over a million lines of code throughout my professional career in VB6 and VB.Net and I see absolutely no problem with using this option. Like anything else in life, you just have to know what you are doing...
"It's almost as bad as making a language case sensitive."
What's the argument against case sensitive languages..? It's one of the reasons I love C#...
Pxtl, typing in Python is dynamic, it is not weak. Everything is most certainly not a var. The following code will result in an error in python:
myVar = 12
myVar = test
@hobbit125: Actually you will not get an error. This is because 12 and text are merely being bound to identifier myVar, not declaring a variable.
I think it is ok for people to program with option strict turned off, I just hope they work for my competitors.
However, my complaint with Option Strict, is that it is not smart enough to NOT throw an error when you assign a subtype to a supertype.
Anyone know what possible purpose this serves?
I can only think of 2 possible reasons:
1. OOP was never intended to be used in VB.net.
2. The background compiler already slows things enough and walking the inheritance tree would make it worse.
I always program with it on because I want it to catch the obvious type problems, but wish it had the C# behavior of knowing you can assign a subtype foo to supertype fooBase without a cast.