Introduction
A section of a program that a programmer suspects of having an error might be 'dry run'. A dry run might also be used to check an algorithm during program design.
Dry run
Dry running a program involves the programmer working through a program on paper, usually using a table called a ‘trace table’. The programmer adds columns for any variables or expressions that are important. When this has been done, the programmer works through the program, line by line, filling into the trace table the values of variables and expressions as they change. By doing this, the programmer can spot the exact position when things start going wrong with the program - when variables suddenly contain unexpected values or expressions don't hold the expected state.
To Dry run a program, you will need the code you want to check, a trace table and sometimes a box, which we can use as a display screen. Anything that is output or written or printed, we will write it in the box instead.
A worked example
Here is an example of a procedure. We originally came across this algorithm in the Nesting section of this website. It can be used (and modified) to produce times tables for children.
1. Declare Num1, Num2, Multiplier, Answer, Counter As Integer
2.
3.
Multipler = 2
4. Num1 = 1
5. Num2 = 3
6.
7. Do While Multiplier < 4
8.
For Counter = Num1 to Num2
9. Answer = Counter * Multiplier
10. Add_to_the_display: Counter & "Times" & Multiplier & " = " & Answer
11. Next Counter
12 Multiplier = Mulitplier + 1
13. Loop
Let us suppose that we want to check if this algorithm works as intended before we code it up. We need to create a Tace Table. We will put all variables and expressions used by our algorithm in the first row and then we will work through the program line by line. Here is our completed Trace Table, with the display screen underneath it:


Let's work through the code ....
- We only put values in boxes when they change.
- Starting at line 1, no values are put into variables. Variables are declared on this line.
- There is no code on line 2.
- In line 3, the Multiplier is set to 2 so we write 2 in the box.
- In line 4, Num1 is assigned to 1 so we write 1 in the box.
- In line 5, Num2 is assigned to 3, so we write 3 in the Num2 box.
- There's no code on line 6.
- In line 7, the expression 'Multiplier < 4' Evaluates to TRUE. The Multiplier holds 2 and 2 is less than 4. So we write TRUE in the correct column and row.
- In line 8, we enter a FOR loop. Counter starts at 1, so we write 1 in the correct row and column.
- In line 9, we calculate answer to be Counter * Multiplier, or 2, so we put 2 in the correct box.
- In line 10, there is an output, so we write the output to our Display screen under the table. 1 Times 2 = 2 is written onto the display screen.
- When we get to Line 11, we jump back to line 8 because the FOR loop hasn't exceeded its upper limit yet.
- On line 8, Counter now becomes 2. We write 2 in the correct row and column.
And so on .....
Q1. Continue to check the Trace Table. Has it been done correctly? Are there any mistakes?
Q2. Why do programmers use Trace tables and dry runs? Why not just use the tools in an IDE (Integrated Development Environment)?
Q3. Look at the following pseudo code:
1. TOTAL=0
2. REPEAT
3. BEGIN
4. READ VALUE
5. TOTAL=TOTAL+VALUE
6. OUTPUT VALUE, TOTAL
7. END
8. UNTIL (TOTAL > 1000)
9. OUTPUT 'Finished'
Dry run the program, putting in the following numbers: Firstly, enter 500, then enter 200, then 300 and then 100. Don't forget to use both a Trace Table and a display screen.
Q4. A factorial function called Fact is called with the value 3. Using a Trace Table and output screen, check to see if the following algorithm works. The Trace Table should begin at line 9. If you need to remind yourself how recursion works, look at this section.
1. Function Fact(K)
2. BEGIN
3. IF K <=1 then
4. Fact := 1
5. ELSE
6. Fact := K x Fact(K-1)
7. END
8.
9. Output Fact (3)
Q5. Repeat the last question with
Output Fact (4)
|