New Variable Scoping in Visual Basic .NET

Now that we've had a chance to contemplate one of the key features of programming in .NET, let's take a look at another new item we need to come to grips with—variable scoping. While you probably understood this very well in classic Visual Basic, the rules have changed a bit for .NET. Thankfully, the way scoping works now gives us more power and is actually more intuitive.

The scope of a variable, constant, or procedure refers to its availability for reference by other parts of your code. Scope is also simply known as the visibility of a variable or procedure. The scope of a declared element is the set of all code that can refer to that element without qualifying its name or making it available through an Imports statement.

The scope of a variable in Visual Basic .NET can be at one of four levels. The most limited level is block-level and the greatest visibility is project-level.

Block-level. Available only within the code block in which it is declared
Procedure-level. Available only within the procedure in which it is declared
Module-level. Available to all procedures within the module, class, or structure in which it is declared
Project-level. Available to all procedures in the project or application

Consider the module shown below. Module-level scope applies equally to modules, classes, and structures. You can declare elements at this level by placing the declaration statement outside any procedure or block within the module, class, or structure. The code below shows a module-level variable, sModuleLevelScope, and a project-level variable, sProjectLevelScope.

Private sModuleLevelScope As String = "" Public sProjectLevelScope As Integer = 5 Public Function myFunction(ByVal N As Integer) As Integer Dim sLocalScope As String = "Hello" If N < 1291 Then Dim bBlockScope As Integer bBlockScope = n ^ 3 End If Return bBlockScope End Function

Elements with module-level scope, such as sModuleLevelScope, that you declare with the Private keyword are available for reference to every procedure in that module. Of course, an element such as this is not available to any code in a different module. The Dim statement at module level defaults to Private access, so it is equivalent to using the Private statement. However, I recommend that you make scope and access more obvious by using the keyword Private.

The other variable, sProjectLevelScope, is declared as Public, which means it is visible anywhere in our project. It can also be read or written to from the outside world.

When you make a declaration at module level, the access you choose determines the scope. The namespace that contains the module, class, or structure also affects the scope.

The variable sModuleLevelScope can be seen only anywhere within the procedure myFunction. This level of visibility is quite similar to classic Visual Basic.

What's new in Visual Basic .NET is the block-scoped variable. We dimension bBlockScope within the If-End If block. Essentially, a block is a set of statements terminated by an End, Else, Loop, or Next statement; for example, within a For...Next or If...Then...Else...End If construction. An element such as bBlockScope that's declared within a block can be used only within that block. In our example, the scope of the bBlockScope integer variable is the block between If and End If. Therefore, bBlockScope can be seen only within the If…End If block and can no longer be referenced when execution passes out of that block. This level of access is the most restrictive level of scope and should be used whenever possible.

Namespace Scope

Namespace scope is a variation of module-level scope. For example, if you declare an element at module level using the Friend or Public statement, it becomes available to all procedures throughout the namespace in which the element is declared. Namespace scope also includes nested namespaces. An element available from within a namespace is also available from within any namespace nested inside that namespace.

If your project does not contain any Namespace statements, everything in the project is in the same namespace. In this case, namespace scope can be thought of as project scope. Elements declared as public in a module, class, or structure are also available to any project that references their project. This is how our variable sProjectLevelScope works.

Determining the Scope of a Variable

Knowing how to scope a variable is important in any language, and Visual Basic .NET is no exception. When considering the scope of a variable, keep in mind that local variables are a good choice for any kind of temporary calculation. They consume memory only when their procedure is running, and their names are not susceptible to conflict with other parts of your program.

For example, you can create several different procedures containing a variable named iTempCounter. As long as each iTempCounter object is declared as a local variable, each procedure recognizes only its own version of iTempCounter. Any one procedure can alter the value of its local iTempCounter without affecting the other variables with the same name in other procedures.

As a rule of thumb, always scope each variable with the narrowest scope possible. This technique not only shows good programming habits, but it will eliminate many subtle bugs and make the most efficient use of memory.