The concept of variable scope encapsulates two key elements. In all the discussion so far of variables, we have not focused on the allocation and deallocation of those variables from memory. The first allocation challenge is related to what happens when you declare two variables with the same name but at different locations in the code. For example, suppose a class declares a variable called myObj that holds a property for that class. Then, within one of that class's methods, you declare a different variable also named myObj . What will happen in that method? Scope defines the lifetime and precedence of every variable you declare, and it handles this question.
Similarly, there is the question of the removal of variables that you are no longer using, so you can free up memory. Chapter 4 covers the collection of variables and memory once it is no longer needed by an application, so this discussion focuses on priority, with the understanding that when a variable is no longer "in scope," it is available to the garbage collector for cleanup.
.NET essentially defines four levels of variable scope. The outermost scope is global. Essentially, just as your source code defines classes, it can also declare variables that exist the entire time that your application runs. These variables have the longest lifetime because they exist as long as your application is executing. Conversely, these variables have the lowest precedence. Thus, if within a class or method you declare another variable with the same name, then the variable with the smaller, more local scope is used before the global version.
After global scope, the next scope is at the class or module level. When you add properties to a class, you are creating variables that will be created with each instance of that class. The methods of that class will then reference those member variables from the class, before looking for any global variables. Note that because these variables are defined within a class, they are only visible to methods within that class. The scope and lifetime of these variables is limited by the lifetime of that class, and when the class is removed from the system, so are those variables. More important, those variables declared in one instance of a class are not visible in other classes or in other instances of the same class (unless you actively expose them, in which case the object instance is used to fully qualify a reference to them).
The next shorter lifetime and smaller scope is that of method variables. When you declare a new variable within a method, such variables, as well as those declared as parameters, are only visible to code that exists within that module. Thus, the method Add wouldn't see or use variables declared in the method Subtract in the same class.
Finally, within a given method are various commands that can encapsulate a block of code (mentioned earlier in this chapter). Commands such as If Then and For Each create blocks of code within a method, and it is possible within this block of code to declare new variables. These variables then have a scope of only that block of code. Thus, variables declared within an If Then block or a For loop only exist within the constraints of the If block or execution of the loop. Creating variables in a For loop is a poor coding practice and performance mistake and should be avoided.
In the .NET environment in general and within Visual Basic in particular, you use objects all the time without even thinking about it. As noted earlier, every variable, every control on a form — in fact, every form — inherits from System.object. When you open a file or interact with a database, you are using objects to do that work.
Was this article helpful?