A variable can be defined as an entity that has the following six properties:
A variable's name is used to identify the variable in code. In VB .NET, a variable name can start with a Unicode alphabetic character or an underscore, and can be followed by additional underscore characters or various Unicode characters, such as alphabetic, numeric, formatting, or combined characters.
Every variable has an associated memory address, which is the location in memory at which the variable's value is stored. Note that in many circumstances, the address of a variable will change during its lifetime, so it would be dangerous to make any assumptions about this address.
The type of a variable, also called its data type, determines the possible values that the variable can assume. We discuss data types in detail later in the chapter.
The value of a variable is the contents of the memory location at the address of the variable. This is also sometimes referred to as the r-value of the variable, since it is what really appears on the right side of an assignment statement. For instance, in the code:
the final statement can be read as "assign the value of i to memory at the address of j." For similar reasons, the address of a variable is sometimes called its l-value.
The scope of a variable determines where in a program that variable is visible to the code. Scope is discussed in detail in this chapter.
A variable's lifetime determines when and for how long a particular variable exists. It may or may not be visible (that is, be in scope) for that entire period.
Variables (and constants) have a scope, which indicates where in the program the variable is recognized or visible to the code, that is, where it can be referred to in code.
Local variables: block-level and procedure-level scope
If a variable is declared inside a code block (a set of statements that is terminated by an End..., Loop, or Next statement), then the variable has block-level scope; that is, it is visible only within that block.
For example, consider the following code:
In this code, the variable rec is not recognized outside the block in which it is defined, so the final statement produces an error.
It is important to note that the lifetime of a variable always refers to the entire procedure, even if the
variable's scope is block-level. (We discuss this in Section 2.1.2 later in this chapter.) This implies that if a block is entered more than once, a block-level variable will retain its value from the previous time the block code was executed.
A variable declared using the Dim keyword within a Visual Basic procedure but not within a code block
has procedure-level scope. Its scope consists of the procedure in which it is declared.
A variable that has block-level scope or procedure-level scope is called a local variable. One of the advantages of local variables is that the same name can be used in different procedures without conflict, since each variable is visible only to its own procedure. Another is that the memory allocated to the variable can be released as soon as control leaves the procedure, making our code easier to maintain.
Module-level and project-level scope
There are differences in the way scope is handled for variables declared in the Declarations section of
a standard module and a class module.
We first note that a standard module itself can be declared using one of the access modifiers Public, Friend, or Private (this is the default). Using such a modifier simply restricts the individual members to that level of access at most. Thus, for instance, a Public variable declared in a Friend module has only Friend scope.
Variables also have a lifetime. The difference between lifetime and scope is quite simple: lifetime refers to when, or at what time during program execution the variable is valid; scope refers to where in the program the variable is recognized by (visible to) the code.
To illustrate the difference, consider the following procedure:
Note that LocalVar is a local variable. When the line:
is executed, execution switches to ProcedureB. While the lines of ProcedureB are being executed, the variable LocalVar is out of scope since it is local to ProcedureA. But it is still valid. In other words, the variable still exists and has a value. It is simply not accessible to the code in ProcedureB. In fact, ProcedureB could also have a local variable named LocalVar, which would have nothing to do with the variable of the same name in ProcedureA.
Once ProcedureB has completed, execution continues in ProcedureA with the line:
which is a valid instruction, since the variable LocalVar is back in scope.
Thus, the lifetime of the local variable LocalVar extends from the moment ProcedureA is entered to the moment it is terminated, including the period during which ProcedureB is being executed as a result of the call to this procedure, even though during that period, LocalVar is out of scope. We mention again that the lifetime of a block-level variable is the lifetime of the procedure in which it is defined.
We have seen that a variable may go in and out of scope during its lifetime. However, once the lifetime of a variable expires, the variable is destroyed and its value is lost. It is the lifetime that determines the existence of a variable; its scope determines its visibility.
Thus, consider the following procedures:
When ProcedureA is executed, it simply calls ProcedureB five times. Each time ProcedureB is called, the local variable x is created anew and destroyed at the end of that call. Thus, x is created and destroyed five times.
Normally, this is just what we want. However, there are times when we would like the lifetime of a local variable to persist longer than the lifetime of the procedure in which it is declared. For example, we may want a procedure to do something special the first time it is called, but not in subsequent times.
A static variable is a local variable whose lifetime is the lifetime of the entire program. The following VB code shows how one might use a static variable:
Note that we can initialize a static variable, provided that we do so within the variable declaration. The
following code illustrates this point:
The first time we hit the button1 command button, StaticTest displays the message True, because the static variable st has been initialized to True. However, all subsequent times we hit the button, StaticTest returns False. This ability to initialize a static variable was missing and was a very annoying oversight in earlier versions of VB.
We could accomplish the same effect by using a module-level variable to keep a record of whether the
procedure has been called, instead of a static local variable. However, it is considered better programming style to use the most restrictive scope possible, which, in this case, is a local variable with an "extended" lifetime. This helps prevent accidental alteration of the variable in other portions of the code. (Remember that this code may be part of a much larger code module, with a lot of things going on.)
VB.NET Related Interview Questions
|VB.NET Interview Questions||ASP.NET Interview Questions|
|ADO.Net Interview Questions||Windows Presentation Foundation(WPF) Interview Questions|
|Windows CE .NET Interview Questions||Dot Net Framework Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Asp Dot Net Mvc Interview Questions|
Variables And Data Types
Introduction To Object-oriented Programming
The .net Framework: General Concepts
The .net Framework Class Library
Delegates And Events
Error Handling In Vb .net
The Language Reference
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.