Option Strict and Option Explicit in VB.NET 2005

I just noticed that Option Explicit is on by default for new VB solutions in Visual Studio .NET 2005:

vsnet_2005_beta2_option_explicit_default.gif

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"
Console.WriteLine(MyStringNam)

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.

Related posts

The Slow Brain Death of VB.NET

It’s amusing that the very people defending VB.NET are, ironically, illustrating precisely why VB.NET is in such trouble: I just want to make it clear that I am one MVP that does NOT intend to sign this petition about VB. And by the way, my background is

By Jeff Atwood ·
Comments

Resharper for VB.NET

Inspired by Jeff Key’s, “If loving Resharper is wrong I don’t wanna be right” soliloquy, I emailed JetBrains to see if they had plans to bring Resharper – currently a C# only tool – to VB.NET. This was their response: Of course there will be support for VB.NET,

By Jeff Atwood ·
Comments

VB.NET vs C#, round two

I saw on Dan Appleman’s blog that a new version of his Visual Basic.NET or C#: Which to Choose? is available, reflecting the latest changes in VS.NET 2005. I immediately bought a copy from Lockergnome, apparently the only vendor that allows instant eBook downloads after purchase.* There

By Jeff Atwood ·
Comments

Stuck in a VB.NET Ghetto

At a recent trinug user group meeting, Richard Hale Shaw was going off on a tirade about how Visual Basic 6 was “the ultimate anti-pattern.” I don’t disagree. VB6 had some serious issues, many of which .NET resolves. Then he put a question to the audience: “What specific things

By Jeff Atwood ·
Comments

Recent Posts

Stay Gold, America

Stay Gold, America

We are at an unprecedented point in American history, and I'm concerned we may lose sight of the American Dream.

By Jeff Atwood ·
Comments
The Great Filter Comes For Us All

The Great Filter Comes For Us All

With a 13 billion year head start on evolution, why haven’t any other forms of life in the universe contacted us by now? (Arrival is a fantastic movie. Watch it, but don’t stop there – read the Story of Your Life novella it was based on for so much

By Jeff Atwood ·
Comments
I Fight For The Users

I Fight For The Users

If you haven’t been able to keep up with my blistering pace of one blog post per year, I don’t blame you. There’s a lot going on right now. It’s a busy time. But let’s pause and take a moment to celebrate that Elon Musk

By Jeff Atwood ·
Comments

The 2030 Self-Driving Car Bet

It’s my honor to announce that John Carmack and I have initiated a friendly bet of $10,000* to the 501(c)(3) charity of the winner’s choice: By January 1st, 2030, completely autonomous self-driving cars meeting SAE J3016 level 5 will be commercially available for passenger use

By Jeff Atwood ·
Comments