Tracing Control-Flow-Heavy Programs

In Part 1, tracing was a straightforward exercise: walk down the program line by line, write down what each variable holds, and read off what gets printed. The programs were short and linear. Each line ran exactly once.

In this part, programs do not work that way. if statements pick a path. for and while loops run the same lines many times. The same skill applies — trace line by line — but the shape of the trace changes.

This chapter shows how to extend the trace tables from Part 1 to handle branching and looping code.

Tracing Matters More Now

Linear code has one path. If you trace it once, you have traced all of it.

Code with branches has many paths. The program that ran when you tested it took one of them. The other paths only get exercised if you give the program different input. Tracing is how you check those paths without having to run the program again and again.

Code with loops compounds this. Each iteration is a small reuse of the same lines, and bugs often hide in either the very first iteration, the very last iteration, or the special case where the loop body runs zero times. Tracing forces you to look at each iteration separately.

The good news is that the underlying habit is the same: predict before running, run, compare. This chapter just sharpens the trace notation to fit the new shapes.

Tracing an if/elif/else

For branching code, a useful extension to the Part 1 trace table is a column showing which branch was taken.

minutes = 45

if minutes < 15:
    response = "Short."
elif minutes <= 90:
    response = "Solid."
else:
    response = "Long."

print(response)

The “branch” column makes it explicit which path the program took. For chains with several elifs, this is the difference between guessing at the behavior and actually knowing it.

A useful trick when tracing branching code: trace the same program twice, with two different inputs that take different branches. If both traces look right, you have evidence that the branches do what you think they do.

minutes = 12

if minutes < 10:
    label = "tiny"
elif minutes < 30:
    label = "short"
else:
    label = "long"

print(label)

minutes < 10: ...
minutes < 30: ...
else: ...
label: ...
output: ...

Tracing a for Loop

For loops, the natural trace shape is one row per iteration.

minutes_list = [45, 30, 60]
total = 0

for minutes in minutes_list:
    total += minutes

print(total)

The “(before loop)” and “(after loop)” rows are deliberately included. The before row reminds you that the accumulator starts at 0. The after row reminds you that anything outside the loop runs once at the end. Most bugs in accumulator loops are about one of these two rows being wrong — the wrong starting value, or the wrong post-loop computation.

Tracing a Loop with an if Inside

Combining the two ideas gives you the shape you need for counting and searching loops:

minutes_list = [10, 45, 90, 20, 75]
long_sessions = 0

for minutes in minutes_list:
    if minutes >= 60:
        long_sessions += 1

print(long_sessions)

The “if taken?” column is what makes this trace useful. You can see at a glance which iterations actually updated the counter and which did not. If the final answer is wrong, you can scan this column and check whether the right iterations triggered the update.

Debug Prints Inside Loops

Debug prints from Part 1 still work inside loops, but they print on every iteration, which can be loud. Two tactics keep them useful:

Tactic 1: Print only when a condition matches.

minutes_list = [10, 45, 90, 20, 75]
long_sessions = 0

for minutes in minutes_list:
    if minutes >= 60:
        print(f"DEBUG: counting {minutes} as long")
        long_sessions += 1

This only prints the iterations that triggered the update. You see exactly the cases that mattered, without scrolling through every iteration.

Tactic 2: Print the final state after the loop.

for minutes in minutes_list:
    if minutes >= 60:
        long_sessions += 1

print(f"DEBUG: long_sessions = {long_sessions}")

This says nothing about what happened inside the loop, but it makes the result obvious before the program does anything else with it.

Both tactics are useful in different situations. The first is good when you suspect the bug is in which iterations triggered an update. The second is good when you suspect the bug is in what happens after the loop.

minutes_list = [10, 80, 25, 120]

(no input)

DEBUG counting 80
DEBUG counting 120
Long sessions: 2

A Walked-Through Example

Here is a small program that is supposed to find the longest session in a list. Read it, predict what it prints with minutes_list = [45, 30, 90, 60, 75], and then trace it.

The function call range(1, len(minutes_list)) produces the numbers from 1 up to but not including len(minutes_list).

minutes_list = [45, 30, 90, 60, 75]
longest = 0

for i in range(1, len(minutes_list)):
    if minutes_list[i] > longest:
        longest = minutes_list[i]

print(f"Longest: {longest}")

A trace, one row per iteration:

The output is Longest: 90. That happens to be the right answer for this input, but the trace exposes two problems:

1. range(1, len(minutes_list)) starts at 1, so iteration never sees minutes_list[0], which is 45. The first item is silently skipped. With this list, the skip happens not to matter because 45 is not the largest. But if the largest item were at position 0 — for example, minutes_list = [90, 30, 45] — the program would give the wrong answer.

2. longest = 0 only works if every item is positive. If the list were all negative numbers (which is unusual for minutes, but the principle holds), longest would stay at 0 and the result would be wrong.

This is the kind of bug that a single test cannot find. The trace is what reveals the gap between “works on this input” and “works on every input”. You will see this pattern again — and learn how to be systematic about it — in the next chapter.

45
30
90

Longest: 90

Check Your Understanding

1. Why is it useful to add a “branch taken” column when tracing an if/elif/else?
2. In a for loop trace, why include explicit “before loop” and “after loop” rows?
3. When debugging a counting loop that gave the wrong answer, which debug-print tactic is more useful: printing every iteration, or printing only the iterations that matched the if?
4. Trace the following program by hand, writing the steps on a piece of paper. What does it print?

total = 0
for x in [3, 6, 9, 12]:
    if x % 2 == 0:
        total += x
print(total)