Reading and Tracing Code

In an exam you are often handed a short program and asked a deceptively simple question: what does it print? There is no computer in front of you to press Run — so you have to become the computer. Working out what a program does by hand, without running it, is called tracing the code (or doing a dry run). It is one of the most valuable skills in all of programming: it lets you predict a program's output, and it is how you hunt down a bug when the code does the wrong thing.

The trick professionals and examiners use is a trace table — a little grid you fill in as you pretend to be the computer. You give it one column for each variable (plus a column for anything the program outputs), and you write a new row every time a value changes. Step through the program one line at a time, updating the table as you go, and by the end the table tells you exactly what happened — no guessing.

A program to trace

Here is a tiny program. It keeps a running total, and a counter n that starts at 5 and counts down. Each pass of the loop adds the current n onto the total and then makes n one smaller, until n reaches 0 and the loop condition n > 0 becomes false.

Don't run it yet. Read it carefully and try to work out the final number in your head or on paper first — then we'll build the trace table together, and afterwards you can press Run to check whether your trace was right.

let total: number = 0; let n: number = 5; while (n > 0) { total = total + n; // add the current n onto the running total n = n - 1; // move n one step closer to 0 } console.log(total);

This adds up 5 + 4 + 3 + 2 + 1. Can you see it? Let's trace it properly to be sure.

Building the trace table, row by row

We use three columns: n, total, and output. We fill in the starting values first, then work through the loop one pass at a time, writing a new row whenever a variable changes. Step through it and watch the numbers appear:

Notice how the very last row is written only after we check the condition n > 0 and find it false. The loop stops, we reach console.log(total), and 15 is printed. If your hand-trace matched the table — and matches the program's real output when you Run it above — you have traced correctly.

The recipe, in words

Any trace, however long, is the same handful of habits:

Draw the columns. One per variable, plus output if the program prints anything.
Write the starting values in the first row, as soon as each variable is created.
Go line by line. Do exactly what each line says — no skipping, no shortcuts. Be the computer, not the clever human.
Add a row only when a value actually changes. A line that just reads a variable (like an if test) changes nothing, so it earns no row.
At a loop, read the condition carefully each time round to decide whether to go again — and note the loop variable's final value when it stops.
When the program ends, read off the answer from the table.

Two reasons. First, in a written exam there is no computer — a clean trace table is exactly how you earn the marks for "state the output of this program". Second, and more importantly, tracing is how you debug. When a program runs but gives the wrong answer, the computer won't tell you why; you have to trace it and compare what the variables should hold at each step against what they actually do. The moment your hand-trace and the real values disagree, you've found the line where the bug lives. Skilled programmers trace little snippets in their heads all day long.

Two classic tracing mistakes cost easy marks:

1. Writing a row when nothing changed. You add a new row only when a variable's value actually changes. A line like if (n > 0) or console.log(total) reads the variables but doesn't alter them — so it gets no new row. Cluttering the table with unchanged rows makes it easy to lose track of which value is current.

2. Misreading the loop condition — especially the final value. Read the condition every time round and decide truthfully whether to loop again. In our program the loop is while (n > 0), so it keeps going while n is 5, 4, 3, 2, 1 and stops the instant n hits 0 — the body does not run when n = 0. A very common slip is to run the body "one more time" at the boundary, or to forget that when the loop exits the counter is left at its final value (0 here, not 1). When an answer is off by one, the loop condition is the first thing to re-check.