In addition to its type, a variable also has a scope. The scope (or visibility) of a variable is the section of the application that can see and manipulate the variable. If a variable is declared within a procedure, only the code in the specific procedure has access to that variable; this variable doesn’t exist for the rest of the application. When the variable’s scope is limited to a procedure, it’s called local.
Suppose that you’re coding the Click event of a button to calculate the sum of all even numbers in the range 0 to 100. One possible implementation is shown in Listing 2.4.
Listing 2.4: Summing Even Numbers
Code language: VB.NET (vbnet)
Private Sub Button1 Click(ByVal sender As Object, _ ByVal e As System.EventArguments) Handles Button1.Click Dim i As Integer Dim Sum As Integer For i = 0 to 100 Step 2 Sum = Sum + i Next MsgBox "The sum is " & Sum.ToString End Sub
The variables i and Sum are local to the Button1 Click() procedure. If you attempt to set the value of the Sum variable from within another procedure, Visual Basic will complain that the variable hasn’t been declared. (Or, if you have turned off the Explicit option, it will create another Sum variable, initialize it to zero, and then use it. But this won’t affect the variable Sum in the Button1 Click() subroutine.) The Sum variable is said to have procedure-level scope: It’s visible within the procedure and invisible outside the procedure.
Sometimes, however, you’ll need to use a variable with a broader scope; a variable that’s available to all procedures within the same file. This variable, which must be declared outside any procedure, is said to have a module-level scope. In principle, you could declare all variables outside the procedures that use them, but this would lead to problems. Every procedure in the file would have access to any variable, and you would need to be extremely careful not to change the value of a variable without good reason. Variables that are needed by a single procedure (such as loop counters) should be declared in that procedure.
Another type of scope is the block-level scope. Variables introduced in a block of code, such as an If statement or a loop, are local to the block but invisible outside the block. Let’s revise the previous code segment so that it calculates the sum of squares. To carry out the calculation, we first compute the square of each value and then sum the squares. The square of each value is stored to a variable that won’t be used outside the loop, so we can define the sqrValue variable in the loop’s block and make it local to this specific loop, as shown in Listing 2.5.
Listing 2.5: A Variable Scoped in Its Own Block
Code language: VB.NET (vbnet)
Private Sub Button1 Click(ByVal sender As Object, _ ByVal e As System.EventArguments) Handles Button1.Click Dim i, Sum As Integer For i = 0 to 100 Step 2 Dim sqrValue As Integer sqrValue = i * i Sum = Sum + sqrValue Next MsgBox "The sum of the squares is " & Sum End Sub
The sqrValue variable is not visible outside the block of the For. . .Next loop. If you attempt to use it before the For statement or after the Next statement, VB will throw an exception.
The sqrValue variable maintains its value between iterations. The block-level variable is not initialized at each iteration, even though there’s a Dim statement in the loop.
Finally, in some situations, the entire application must access a certain variable. In this case, the variable must be declared as Public. Public variables have a global scope: They are visible from any part of the application. To declare a public variable, use the Public statement in place of the Dim statement. Moreover, you can’t declare public variables in a procedure. If you have multiple forms in your application and you want the code in one form to see a certain variable in another form, you can use the Public modifier.
The Public keyword makes the variable available not only to the entire project, but also to all projects that reference the current project. If you want your variables to be public within a project (in other words, available to all procedures in any module in the project) but invisible to referencing projects, use the Friend keyword in the declaration of the module. Variables you want to use throughout your project, but to not become available to other projects that reference this one, should be declared as Friend.
So, why do we need so many types of scope? You’ll develop a better understanding of scope and which type of scope to use for each variable as you get involved in larger projects. In general, you should try to limit the scope of your variables as much as possible. If all variables were declared within procedures, you could use the same name for storing a temporary value in each procedure and be sure that one procedure’s variables wouldn’t interfere with those of another procedure, even if you use the same name.