This is a series on setting compiler options for Visual Studio VB.NET projects, versions 2005-2010. Compiler options are project-level settings that determine how the compiler behaves when it compiles your code. You view and set compiler options in the Compile tab of the project properties sheet (Figure A).
I'm not going to get into a philosophical discussion of whether people should be writing code in VB.NET. The reality is that some do, and they need this information. My aim here is to provide information to those who have chosen to (or must) use VB.NET.
This is a pretty high-level discussion of compiler options-by which I mean it's from the viewpoint of the programmer looking at the options within the VS IDE and wondering about them. The options you see in the IDE are a simplified picture of the 100+ options actually available to the compiler. It is my assumption that the ones reading this article are more interested in the options available via the IDE than in going below the surface.
In this series, I will explain each of the options presented in the IDE as applying to all configurations, and recommend how to set them. Figure B shows a list of the options as of version 2010.
First, let me list the options along with their default values (i.e., as installed):
|Option infer (2010)||On|
|Late binding; call could fail at run time||None|
|Implicit type; object assumed||None|
|Use of variable prior to assignment||Warning|
|Function/Operator without return value||Warning|
|Unused local variable||Warning|
|Instance variable accesses shared member||Warning|
|Recursive operator or property access||Warning|
|Duplicate or overlapping catch blocks||Warning|
In this first part, Part 1, I will discuss the first option, Option Explicit.
What it means
Option Explicit determines whether VB.NET requires explicit variable declarations. Visual Basic is an old language with lots of forgiving rules, so unless you tell it otherwise, it will let you use a variable without declaring it, as I've done here:
Private Function GetPostalCode()
UndeclaredVariable = "22205-7509"
When was my mystery variable created? The first time I used it. I didn't have to declare it at all. This is how VB.NET behaves with Option Explicit set to Off.
Setting Option Explicit to On (the default) forces you to declare all variables before using them, as here:
Private Function GetPostalCode()
DeclaredVariable = "22205-7509"
Now the compiler is not allowed to create the variable the first time I use it. I must declare it first.
Why it's important
The chief hazard of skipping variable declaration is unintentional variable creation. With Option Explicit Off, lines you write that create variables look exactly like lines you write that use them. This means that you can easily create variables just by misspelling variables you intended to use. Since misspelling is unintentional, doing this typically leads to hard-to-find bugs. This hazard is especially prevalent in long routines and large programs. Imagine this very contrived scenario:
Private Function GetFormattedPostalCode()
MysteryVariable = "22205"
Separator = "-"
ThirdPart = "7509"
If ThirdPart.Length > 0 Then
MysteryVeriable = MysteryVariable & Separator & ThirdPart
That routine will always return 22205, because it unintentionally creates a new variable in the If..Then clause-a variable that is never used. Turning Option Explicit On simply will not let that happen.
What to do with it
If it's your project and you have a choice, you should leave Option Explicit set to On. There's really no reason to turn it off. And if you do turn it off, you will lower the shields protecting your program, with no benefit to you except the dubious benefit of typing less-a false benefit, since you will have to do a lot more typing in the course of finding, fixing, and trying to explain the bugs that result from it.
What if it's not your project? If you have inherited someone else's project whose Option Explicit is set to Off, turn it on and see if the project even compiles-it won't if even one variable lacks a declaration. In that case, go through all of the errors that land on undeclared variables and declare them. But be careful and fix them one at a time-you may find more than one unintentionally-created variable, and if you do, you will have to make sure you understand the intended outcome, and that the change gets you there. It may not be straightforward.
If the project does compile, you should be good to go.
Option Explicit has been with Visual Basic in its various forms for a long time. That's because the language itself doesn't require variable declarations. But the hazards of not declaring variables outweigh any supposed benefits. Set Option Explicit to On in all your VB.NET projects.