When a program doesn't work due to a logic error it can sometimes be difficult to find the problem, even with rubberducking. Trace tables follow the execution of a program a line at a time, noting the value of each variable on a new row each time it changes. This technique also known as "dry-running" is essential for answering GCSE examination questions but is also a useful last-resort debugging technique.
If you know the error is confined to one subprogram, it is only necessary to trace that subprogram. Another good reason for structured programming.
Draw a table and go through every line of code in the program. Whenever you discover a new variable, write the name of the variable as a column heading in the table and then its initial value in the first row. For parameters that may have different values passed into the subprogram, you can assign valid inputs in the first row of the table.
Once all the variables and their initial values have been identified, go through the program a line at a time as a CPU would, starting in the main program section. Each time a variable changes, write its new value in the next row.
Sample program:
def show_value(value, resale_value):
year = 0
depreciation = 0.25
while value >= resale_value and resale_value > 0:
print("In year", year, "the car is worth £", value)
value = int(value - (value * depreciation))
year = year + 1
print("Part exchange before the end of year", year)
Sample trace table:
value | resale_value | year | depreciation |
---|---|---|---|
5000 | 2000 | 0 | 0.25 |
3750 | 1 | ||
2812 | 2 | ||
2109 | 3 | ||
4 |
A variation of the test table copies each value into the new row even if that variable has not changed to avoid any blank cells. The final row is then the final values of the variables at the end of the program. Another variation shows the output window to include all print statements too.
Trace table are great whole class activities. Give the students a subprogram from one of the learning or practice programs and use it for a trace table exercise.