Local variables knowledge
Local Variables
When a subroutine needs to store data temporarily while it carries out its task, it can declare its own variables. These are called local variables because they belong exclusively to that subroutine. Local variables have two defining characteristics that set them apart from variables declared at the top level of a program:
- Limited lifetime: a local variable is created when the subroutine starts executing and is destroyed when the subroutine finishes. It does not persist between calls.
- Limited scope: a local variable can only be read or changed from within the subroutine that declared it. Code outside that subroutine cannot see or use it.
Together these two properties mean that local variables are completely isolated from the rest of the program. This is part of a broader idea called scope, which describes the part of a program where a variable is visible and usable - explored further in the next benchmark.
Local Variables in Practice
The three examples below each highlight a different aspect of local variable behaviour. Select a tab, then choose a language.
total is declared inside addNumbers(). It is used freely within the function, but any attempt to access it from outside the function causes an error - the variable simply does not exist there.
# Python -- local variable: accessible inside, not outside
def addNumbers(a, b):
total = a + b # total is a LOCAL variable -- only exists here
print("Inside: " + str(total)) # works fine
addNumbers(3, 7)
# print(total) # ERROR: total does not exist outside the function
' VB.NET -- local variable: accessible inside, not outside
Function addNumbers(ByVal a As Integer, ByVal b As Integer) As Integer
Dim total As Integer = a + b ' total is a LOCAL variable -- only exists here
Console.WriteLine("Inside: " & total) ' works fine
Return total
End Function
addNumbers(3, 7)
' Console.WriteLine(total) ' ERROR: total does not exist outside the function
// C# -- local variable: accessible inside, not outside
static int AddNumbers(int a, int b)
{
int total = a + b; // total is a LOCAL variable -- only exists here
Console.WriteLine("Inside: " + total); // works fine
return total;
}
AddNumbers(3, 7);
// Console.WriteLine(total); // ERROR: total does not exist outside the function
Because local variables are isolated inside their own subroutine, two different subroutines can each declare a variable called result without any conflict. Each result is a completely separate variable - changing one has no effect on the other.
# Python -- two subroutines both use a local variable called "result"; no clash
def addNumbers(a, b):
result = a + b # this "result" belongs only to addNumbers
return result
def multiplyNumbers(a, b):
result = a * b # this "result" belongs only to multiplyNumbers -- separate variable
return result
print(addNumbers(4, 5)) # outputs 9
print(multiplyNumbers(4, 5)) # outputs 20; the two "result" variables never interfere
' VB.NET -- two subroutines both use a local variable called "result"; no clash
Function addNumbers(ByVal a As Integer, ByVal b As Integer) As Integer
Dim result As Integer = a + b ' this "result" belongs only to addNumbers
Return result
End Function
Function multiplyNumbers(ByVal a As Integer, ByVal b As Integer) As Integer
Dim result As Integer = a * b ' this "result" belongs only to multiplyNumbers
Return result
End Function
Console.WriteLine(addNumbers(4, 5)) ' outputs 9
Console.WriteLine(multiplyNumbers(4, 5)) ' outputs 20; the two "result" variables never interfere
// C# -- two subroutines both use a local variable called "result"; no clash
static int AddNumbers(int a, int b)
{
int result = a + b; // this "result" belongs only to AddNumbers
return result;
}
static int MultiplyNumbers(int a, int b)
{
int result = a * b; // this "result" belongs only to MultiplyNumbers
return result;
}
Console.WriteLine(AddNumbers(4, 5)); // outputs 9
Console.WriteLine(MultiplyNumbers(4, 5)); // outputs 20; the two "result" variables never interfere
A local variable does not retain its value between calls. Each time the subroutine runs, the variable is created fresh. The example below confirms this: counter always starts at 0 at the beginning of each call and is destroyed when the call ends - it never accumulates across calls.
# Python -- local variable does not persist between calls
def showCount():
counter = 0 # created fresh every time the subroutine is called
counter = counter + 1
print("Counter: " + str(counter)) # always prints 1 -- never accumulates
showCount() # prints: Counter: 1
showCount() # prints: Counter: 1 (counter starts at 0 again -- not remembered)
showCount() # prints: Counter: 1
' VB.NET -- local variable does not persist between calls
Sub showCount()
Dim counter As Integer = 0 ' created fresh every time the subroutine is called
counter = counter + 1
Console.WriteLine("Counter: " & counter) ' always prints 1 -- never accumulates
End Sub
showCount() ' prints: Counter: 1
showCount() ' prints: Counter: 1 (counter starts at 0 again -- not remembered)
showCount() ' prints: Counter: 1
// C# -- local variable does not persist between calls
static void ShowCount()
{
int counter = 0; // created fresh every time the subroutine is called
counter = counter + 1;
Console.WriteLine("Counter: " + counter); // always prints 1 -- never accumulates
}
ShowCount(); // prints: Counter: 1
ShowCount(); // prints: Counter: 1 (counter starts at 0 again -- not remembered)
ShowCount(); // prints: Counter: 1
Key Takeaways
- A local variable is declared inside a subroutine and belongs exclusively to that subroutine.
- Local variables only exist while the subroutine is executing - they are created on entry and destroyed on exit, so their value is not remembered between calls.
- Local variables are only accessible within the subroutine that declared them - code outside cannot read or modify them.
- Two subroutines can each have a local variable with the same name without any conflict - they are entirely separate variables with no connection to each other.
- The visibility of a variable in a program is known as its scope - local variables have a narrow scope limited to their subroutine, which is explored further in the next benchmark.