A routine declares an empty band variable and assigns it in each branch below — what change removes that variable?

## Where the empty variable comes from A routine that maps a numeric score to a band very often looks like this: a name declared at the top with nothing useful in it, a ladder of branches below, each writing into that name, and a use of the name at the end. It is worth being precise about *why* that shape appears, because the reason is mechanical rather than stylistic. The branch is a **statement**: it is executed for its effect and denotes no value. Since it denotes nothing, nothing can be bound to it. But the routine still needs the result of the choice further down. The only way to get a value out of a construct that produces none is to have it write into storage that already exists — so the storage is created first, empty, and the branches fill it in. **The mutable temporary is the workaround for a construct that yields nothing**, not a design decision anybody made on purpose. ## What the workaround costs - **It must be mutable.** The name has to be writable after its declaration, which means any later edit anywhere below can reassign it, and a reader cannot trust a single reading. - **It can be read before it is meaningful.** Between the declaration and the branches, the name exists and holds the placeholder. Anything inserted there sees it. - **No path is obliged to write it.** The ladder may fall through with nothing matching. The variable then keeps its placeholder and travels onward as if it were a real band. - **The value is spread out.** To learn what the name finally holds, a reader has to read every arm of the ladder and remember which one fires. - **It widens scope.** The name is declared in the enclosing scope purely so the branches can reach it, even though only the final use needs it. ## The rewrite ```pseudocode // the temporary exists only because the branch yields nothing set band to nothing if score >= 90 then set band to "distinction" else if score >= 50 then set band to "pass" end // nothing assigned band when score < 50: it is still nothing here record(band) // the choice itself denotes a value, so the name is bound once constant band = if score >= 90 then "distinction" else if score >= 50 then "pass" else "fail" record(band) ``` The second shape answers the reader's question — *what is `band`?* — in one place. It also makes the hole in the first shape impossible to leave open: a form that has to denote a value has to denote one on the path where the score is below fifty, so that path must be written down. In the first shape the same omission was silent, and the defect surfaced far away, wherever the placeholder was finally used. ## What the rewrite does and does not change | aspect | statement shape | value-denoting shape | |---|---|---| | binding | mutable, written later | bound once at its declaration | | where the result is decided | across every arm | in the single form | | an unhandled case | leaves the placeholder | has no value to denote | | scope of the name | the whole enclosing block | narrow, at the point of use | | which arm runs | the matching one | the matching one, unchanged | | order of evaluation | tests top to bottom | tests top to bottom, unchanged | The last two rows matter as much as the first four, and candidates often get them wrong in the exciting direction. This is not a performance change and not a control-flow change. The same test is evaluated first, the same arm is selected, the same string comes out. What moves is *where the value is produced* and therefore what the compiler and the reader can each guarantee about the name. ## When the temporary is still the honest shape Three cases keep it: 1. **The arms do genuinely different things.** If one arm records an event and another sends a notification, they are not producing a value at all; making them fake one is worse than leaving them as statements. 2. **The arms both produce a value and perform an effect.** Then the form denotes something but also acts, and folding it into a larger expression buries the action inside it. 3. **The language does not offer a value-denoting choice.** Some do not. The usual substitute is to move the ladder into a small named function and bind the name to the call — which restores every property above, because a call denotes a value. That third case is the practical takeaway for a mixed codebase. Where the choice cannot denote a value directly, extracting it into a function whose result is the band gets you the same single, immutable, locally-scoped binding, and the ladder stops being something a reader has to trace.