Understanding Variables

Learning objectives

• Distinguish declaration, initialisation, assignment, mutation, scope and lifetime in small C++ examples.
• Trace variable values through a sequence of assignments and identify the first invalid state transition.
• Explain why reading an uninitialised automatic variable in C++ is undefined behaviour, not merely an unpredictable result.
• Justify whether a value should be mutable, const, local, parameterised, renamed, removed or retained as a meaningful intermediate.
• Evaluate competing refactors using evidence about readability, correctness, invariants, scope and failure modes.

Key vocabulary before you start

Worked example: variables as a state model

The supplied Canvas lesson began a C++ average example. This version keeps the same intent but makes the state model explicit: inputs, derived values, invariant and output.

// Calculate the average of three exam scores
#include <iostream>

int main() {
    const int score1 = 78;
    const int score2 = 85;
    const int score3 = 92;

    const int totalMarks = score1 + score2 + score3;
    const double averageScore = totalMarks / 3.0;
    const bool hasPassed = averageScore >= 50.0;

    std::cout << "Average score: " << averageScore
              << " passed? " << (hasPassed ? "yes" : "no") << '\n';
    return 0;
}

Visual model: variable lifecycle and failure points

Use this model to ask where a value first becomes valid, where it is allowed to change, and where it stops being relevant.

Variables as program state

A variable is a source-code entity that names a value or object within a particular scope and lifetime. Some variables are deliberately mutable; others are fixed after initialisation with const. Both forms matter because both shape the program's state model.

Variables help computation progress, but they also create failure modes: assignment to the wrong value, reading before initialisation, reuse for a different meaning, a lifetime that is too long, or a scope that allows too many writes.

At Masters level, the question is not simply what type a variable has. The stronger question is what role it plays in the model of the program and what invariant makes its value valid.

Use fewer variables only when fewer variables preserve meaning

A redundant variable adds state without adding meaning. It may become stale, be read by mistake or hide the real relationship between values.

However, the rule is not 'fewer variables are always better'. A single-use variable may be worth keeping if it names a domain concept, prevents a repeated expression from drifting, clarifies a boundary condition or gives the debugger a useful checkpoint.

Professional judgement is the ability to defend the trade-off: does this name reduce the reader's reasoning burden more than it increases the program's state surface?

Declaration, initialisation and assignment are different operations

A declaration introduces a name and type. Initialisation gives the object its first value. Assignment changes the value of an existing object. Confusing these operations leads to weak explanations and, in C++, real defects.

For an automatic local variable such as int maxVal;, no useful integer value is created by default. Reading it before initialisation is undefined behaviour. That is stronger than saying the program reads 'garbage': the C++ program has stepped outside the language's guarantees.

Good variable design therefore starts by asking: where is the first valid value established, and what later operations are allowed to change it?

int maxVal;          // declaration only
int count = 0;       // declaration with initialisation
std::cin >> count;   // assignment through input
if (count > maxVal)  // first read of maxVal: unsafe
{
    maxVal = count;
}

Meaningful identifiers reduce reasoning risk

An identifier is a source-code name chosen by the programmer. The compiler does not need averageScore to understand the calculation, but a maintainer does.

Clear names reduce the distance between the program and the problem. They make code easier to review because they carry intent at the point where state is read, created or changed.

Poor names are not merely style defects. They can misrepresent whether state is current, validated, temporary, derived, user-supplied or safe to reuse.

Variables are source names, not guaranteed runtime boxes

Variables exist as named entities in source code. After compilation, the generated program may represent their values in registers, memory, immediate constants or optimised expressions. With debug symbols, names may remain available to tooling; without them, the running machine code does not need the source identifier.

This matters because source-level reasoning and runtime behaviour are connected but not identical. Optimisation can remove a variable that was useful to the programmer, while low-level memory errors can corrupt state that looked separate in source code.

A professional programmer therefore learns to reason at two levels: the readable source-code model and the lower-level state changes created by compilation, execution and optimisation.

Variables are one pressure point for correctness

Not every software defect is a variable defect: requirements, algorithms, I/O, concurrency and control flow can also be wrong. But many defects become visible as invalid state.

A variable with broad scope can be changed from too many places. A variable with an unclear name can be misunderstood. A variable with a stale value can make code appear logical while silently carrying an old assumption.

Debugging often means finding the earliest point where expected state and actual state diverge, then explaining why the program allowed that transition.

Scope and lifetime should match the variable's responsibility

Scope controls where a name can be used. Lifetime controls how long the object or value exists. A variable declared earlier or wider than necessary invites accidental reads and writes.

A narrow scope is not a decoration; it is a correctness tool. It makes illegal states harder to express and helps reviewers see when a variable is no longer relevant.

The strongest C++ habit is to initialise at the point of declaration wherever possible, mark non-changing values as const, and delay declarations until the program can provide a valid first value.

Debugging by watching state transitions

Watching variables is useful only when the watch list is tied to a claim about the program. Watching everything creates noise; watching the variables that define the current invariant creates evidence.

The useful debugging question is not merely where the program crashed. It is which state transition first departed from the expected model, and what operation made that transition possible.

A good debugger explanation names the variable, the expected value or range, the actual value, and the line where the invalid transition first appears.

Applied case lab

Applied task: audit and refactor variable state

Work through the stages in order: first classify and name state, then tighten scope and lifetime, then debug invalid state, then defend a trade-off.

Stage 1: state and naming

// Compute average and pass/fail (threshold 50)
#include <iostream>

int main() {
    int a = 78;      // exam 1
    int b = 85;      // exam 2
    int c = 92;      // exam 3
    int tmp = a;     // suspicious
    int total = 0;
    total = a + b + c;
    double avg;      // declared before a valid value exists
    avg = total / 3.0;
    bool t = true;   // defaulted, then conditionally overwritten
    if (avg < 50.0) { t = false; }

    std::cout << "Average: " << avg << " passed? " << (t ? "yes" : "no") << '\n';
    return 0;
}

// Compute average and pass/fail (threshold 50)
#include <iostream>

int main() {
    const int examScore1 = 78;
    const int examScore2 = 85;
    const int examScore3 = 92;
    const int passThreshold = 50;

    const int totalMarks = examScore1 + examScore2 + examScore3;
    const double averageScore = totalMarks / 3.0;
    const bool hasPassed = averageScore >= passThreshold;

    std::cout << "Average: " << averageScore << " passed? " << (hasPassed ? "yes" : "no") << '\n';
    return 0;
}

int count;
std::cin >> count;
int total = 0;
double average;
average = total / static_cast<double>(count);
std::cout << average << '\n';

int count;
std::cin >> count;

if (count <= 0) {
    std::cout << "No scores supplied.\n";
    return 0;
}

const int total = 0;
const double average = total / static_cast<double>(count);
std::cout << average << '\n';

Stage 2: scope and lifetime

double average;
int n; std::cin >> n;
int sum = 0;
for (int i = 0; i < n; ++i) {
    int v; std::cin >> v;
    sum += v;
}
average = sum / static_cast<double>(n);
std::cout << "Average: " << average << '\n';

int count;
std::cin >> count;

if (count <= 0) {
    std::cout << "No scores supplied.\n";
    return 0;
}

int totalScore = 0;
for (int index = 0; index < count; ++index) {
    int score;
    std::cin >> score;
    totalScore += score;
}

const double averageScore = totalScore / static_cast<double>(count);
std::cout << "Average: " << averageScore << '\n';

Stage 3: undefined behaviour and debugging

#include <iostream>

int main() {
    int maxVal; // declaration only: no valid value yet
    int count;
    std::cin >> count;

    for (int i = 0; i < count; ++i) {
        int val;
        std::cin >> val;
        if (val > maxVal) { // reads maxVal before initialisation
            maxVal = val;
        }
    }

    std::cout << "Max: " << maxVal << '\n';
    return 0;
}

#include <iostream>

int main() {
    int count;
    std::cin >> count;

    if (count <= 0) {
        std::cout << "No values supplied.\n";
        return 0;
    }

    int maxVal;
    std::cin >> maxVal; // first-element initialisation establishes valid state

    for (int i = 1; i < count; ++i) {
        int val;
        std::cin >> val;
        if (val > maxVal) {
            maxVal = val;
        }
    }

    std::cout << "Max: " << maxVal << '\n';
    return 0;
}

Stage 4: trade-off judgement

Version 1:
std::cout << (totalMarks / 3.0 >= 50.0 ? "pass" : "fail") << '\n';

Version 2:
const double averageScore = totalMarks / 3.0;
const bool hasPassed = averageScore >= passThreshold;
std::cout << (hasPassed ? "pass" : "fail") << '\n';

Quick checks

AI-augmented practice notes

Use these as prompts for disciplined support, not as permission to outsource judgement.

Assessment tasks

1. Produce a state table for the worked average example, showing each variable immediately after declaration or initialisation.
2. Refactor one supplied snippet to remove one redundant variable, retain one useful single-use variable and justify both decisions.
3. Explain one undefined-behaviour risk caused by uninitialised state and show the first line where the invalid read occurs.
4. Write a short design justification comparing two acceptable variable designs using readability, invariant protection and maintainability.

Judgement questions