Reeborg: Debugging Aids

Reeborg the Robot

Debugging Aids

Changing Execution Speed
"Commenting Out" code
Execution modes

Debugging is the process of finding and reducing the number of bugs, or defects, in a computer program. Straightforward scrutiny of the program, and playing out the way it executes in your head, reveals a surprising number of the bugs. However sometimes you need extra help. For example, the program executes so quickly, you find it hard to follow. Or perhaps you aren't sure if a function you have written is even being invoked and executed. The following debugging aids may help in those cases.

Changing Execution Speed

On the top of the rur tool bar you will find the execution speed slider. Moving the slider to the left will slow down the rate at which Reeborg executes instructions. If you want to hurry things up, moving the slider to the right increases the execution speed. You cannot change the execution speed while Reeborg is running. You must set the slider before you press the green execute button for the new speed setting to be in effect.

While a program is running, each statement is highlighted in the edit pane as it gets executed. Watching will allow you to trace the actual flow of control through your program.

"Commenting Out" code

"Commenting Out" code is one of the simplest, yet effective, ways of pinpointing bugs/defects in a program. There are two ways of making comments in Python:

Single-line comments: Single-line comments begin with the hash character ("#") and are terminated by the end of line. Python ignores all text that comes after the # to the end of the line.
Multi-line comments: Comments spanning more than one line are achieved by inserting a multi-line string (with """ as the delimiter one each end) .

Let's show this by using an example:

#this is a comment in Python

print "Hello World" #This is also a comment in Python

""" This is an example of a multiline
comment that spans multiple lines
...
"""

To illustrate using comments to find where a program defect resides in a program, consider the following program fragment that, when executed, is known to cause an execution problem:

    jump_up()
    move_across()
    jump_down()

To find out why Reeborg is going on some crazy path, we can turn the last two function calls into comments, like this:

    jump_up()
    """
    move_across()
    jump_down()
    """

Because the interpreter ignores comments (that is, does not try to execute a comment), the move_across and jump_down functions will not be invoked. Admittedly, we could have simply deleted the calls but then we would have had to remember what we had written when it comes time to reinsert the code. If Reeborg "jumps up" as intended, we can move the """ down, like this:

    jump_up()
    move_across()
    """
    jump_down()
    """

and see what happens. If we now discover that Reeborg does not behave as intended, we have narrowed down the bug to inside the move_across function. Once we have repaired the move_across function, we can remove all of the comment delimiters.

(NOTE: Once finished debugging, be sure to check that no code remains commented out. It is considered a bad practice to submit any program that still contains commented out code; see the article Code in Comments for a discussion on why this is a bad practice.)

Execution modes:

By default, Reeborg executes in Continuous mode when you press the green

run button. However it is possible to pause execution of a running Reeborg program by pressing the

pause button. You can also stop execution of a running Reeborg program by pressing the

stop button; this essentially issues an instant turn_off() to Reeborg. Using the

single step execution button, you can run a program a statement at a time; each press of the button advances execution to the next instruction.

When All Else Fails . . .

Leave the problem alone and get some rest.
Often even a short break will allow your mental processes to get back on track to finding the source of your problem!

Some final advice: Often programming errors are hard to find but, once discovered, painfully obvious. Do not be too upset with yourself when you find these errors. If you find a "stupid" error, do not think "I'm really dumb"; instead think "I must be a genius to locate such an obscure and hard-to-spot error!" Granted, both are overstatements, but the second is closer to the truth than the first.

Prior Topic | Next Topic

Return to Reeborg home page