4.1.1.13–4.1.1.14 - Local and global variable scope (VB.NET)

Lifetime and visibility

Scope describes where code may refer to a name. Lifetime describes how long the variable's storage exists. These are different questions: a value can exist while the current piece of code cannot access its name.

An ordinary Dim variable declared inside a subroutine is local. Code outside that routine cannot access it by its local name. Each call has its own local state, which exists during that invocation and is discarded when it returns. Two routines may both declare total without sharing one variable. Recursive calls similarly have separate locals, even though the source declaration is the same.

Module Program
    Sub ShowNext(ByVal start As Integer)
        Dim nextNumber As Integer = start + 1
        Console.WriteLine(nextNumber)
    End Sub

    Sub Main()
        ShowNext(4)
        ShowNext(9)
    End Sub
End Module

The outputs are 5 and 10. nextNumber from the first call is not reused by the second. Adding Console.WriteLine(nextNumber) to Main would be invalid: Main is outside its scope. Passing back a result explicitly would be appropriate if the caller needed it.

VB.NET also allows block scope: a name declared inside an If block is accessible only inside that block. Do not infer lifetime solely from block visibility. The syllabus's ordinary local-variable model does not describe a deliberate Static local: VB.NET Static keeps its value between calls but its name remains local. These examples use ordinary Dim locals.

Global state and side effects

A global variable has wider shared visibility and a lifetime beyond one routine call. In this single-module VB.NET program, a Private module-level field is shared by all routines in that module; it is not visible to every module in a larger application. Public would widen access further. State exactly which code shares the variable instead of assuming that global means universally accessible.

Module Program
    Private total As Integer = 20

    Sub Demonstrate()
        Dim total As Integer = 3
        total += 2
        Console.WriteLine(total)
        Program.total += 1
    End Sub

    Sub Main()
        Demonstrate()
        Demonstrate()
        Console.WriteLine(total)
    End Sub
End Module

The local name shadows the module-level name inside Demonstrate. Unqualified total refers to the local value, so each call prints 5. Program.total explicitly changes shared module state: 20 becomes 21 then 22. The last output is 22. There are two variables with the same spelling, not one variable that becomes local during a call.

A side effect changes something beyond the routine's returned result, such as global state or an object passed in. Global state can be appropriate for deliberately shared application information, but hidden dependencies make testing and reuse harder. Calling a routine in a different order may change its result because another routine changed a global first. A local accumulator avoids that interference and makes each call independent.