2. The Variable

Lesson 2 extension · a variable must represent something

What does the variable remember?

I can recognise int score{120}; as a variable declaration. That is useful, but it is not yet an understanding of the program. What does 120 mean? Which values are permitted? Who may change it, and which later decision will use it? A score, a frame number and a temperature could all be represented by an int, yet confusing one for another would still produce an inappropriate program. The declaration gives the compiler a type. The program must give the value a meaning.

This becomes particularly important when the source was written by somebody else or generated by a system. A plausible identifier and a type do not establish that the state model is correct. I still need to know where the value came from, which operations may change it, what must remain true after each change, and what will fail if the value is wrong. A variable remembers part of the program's state. It also creates a responsibility to account for every permitted transition.

A name is not the value

Consider int score{120};. Four related things are present, and muddling them produces muddled explanations. score is the identifier used in this scope. The type is int. An object of that type exists during execution, and the value currently held by that object is 120. A later assignment may replace 120 while the identifier and type remain unchanged. Therefore, saying that “the variable is 120” is convenient shorthand, but a programmer must be able to give the more precise account when correctness depends upon it.

Initialisation supplies the first value as the object begins its lifetime. Assignment replaces the value of an object that already exists. Both examples contain an equals sign, which makes them look more alike than they are. Read the complete statement:

int score{120};   // definition and initialisation
score = 145;      // assignment to an existing object

A local fundamental object written as int score; has no initial value supplied by the programmer. In C++20, reading that indeterminate value can produce undefined behaviour. The useful rule is straightforward: give a local variable a meaningful first value at its definition. Hoping that every possible route through the program performs an assignment before the first read is not a substitute for establishing the initial state.

Follow the value through the program

The following program contains little syntax, but it has a complete state history. For each assignment, first evaluate the expression on the right using the current values; only then replace the object named on the left. Read the assignment as a transition, not as an isolated line:

#include <iostream>

int main() {
    int score{120};
    const int collectedPoints{25};

    score = score + collectedPoints;
    std::cout << "After collection: " << score << '\n';

    const int penalty{10};
    score = score - penalty;
    std::cout << "After penalty: " << score << '\n';
}

The two constants provide inputs to the transitions. Marking them const records that these objects are not intended to change after initialisation. The mutable object is reserved for the state that genuinely evolves. This tells the reader more than declaring everything mutable merely because the language permits it.

The expected output is After collection: 145, followed by After penalty: 135. What does that result prove? It supports the trace for these starting values and these two operations. It does not prove that a negative collection is rejected, that overflow is impossible or that every caller changes the score appropriately. If the output differs, the table gives us exact states to compare. Debugging becomes the search for the first transition at which the observed state leaves the required trace.

Who is allowed to change it?

A calculation does not need to be complicated to create a difficult state error. It is enough to let too many parts of the program change the same value. If five functions may alter a score, I must understand five sets of assumptions and every ordering in which those functions can run. Narrow scope, a meaningful identifier and a clear owner reduce the number of places in which the state can become wrong.

The earlier suggestion that a variable assigned only once is necessarily redundant must therefore be used as a question, not a verdict. A named intermediate value may expose meaning, prevent repeated work or make a debugger trace easier to understand. Conversely, a value assigned many times may reveal confused responsibility. Count assignments if the count points towards something worth inspecting. Decide by asking whether the object represents a necessary value and whether its permitted changes are clear.

Suppose the score starts at zero and the player collects ten points. I put a breakpoint on the assignment and watch the value become ten. Next I send an event that ought to be rejected. Does the score stay at ten? I then inspect the rendering function. It needs to read the score, but what requirement would justify letting it change the score? This investigation identifies the owner, the permitted transitions and the point at which a lower bound must be enforced. If the answer requires a hunt through five unrelated functions, responsibility for the state is not clear enough.

Test the state model

Take one short function from the exercises in this lesson. Choose a variable that changes and write down its intended meaning, initial value, permitted changes and required range. Predict its value after each statement before running the program. Then observe the same value in the debugger and locate the first difference, if one appears. Finally, identify one part of the program that may read the value but has no reason to change it. This is more demanding than recognising the declaration, which is precisely why it teaches more.

A variable should leave the reader able to say what is remembered, why it exists, who may change it and what must remain true. That account scales from a five-line example to a large engine. The number of variables grows. The responsibility to explain the state does not disappear with the size of the program.