The rest of this webpage is organized into the following sections:
This lecture was originally written for Turbo Pascal, then updated for the first ANSI C standard, then object-free C++. It does not address anything specific about object-oriented or real-time programming. I am confident that the general advice will apply well to those types of programming too.
When you wrote your program you thought it would work, but now you've found that it doesn't. `What's wrong? How can you fix it?' That's debugging. Debugging is not the same as fixing syntax errors that prevent compilation.
`The term originated with the first tube computers':
Talk about Grace Hopper and the moth (from 1947).
Tracing the execution will help you to understand what is happening with your program. If you know which part is wrong then you can trace just that part.
We call the written form of our program `code', as in difficult-to-understand. It must be written in a language that the computer can process but that does not mean that is has to be written so that we cannot understand it too. It is hard enough to read code when we think we know what we are instructing the computer to do. But especially when we know that the program doesn't work right then we need to have clear code and clear output.
Your output will appear `immediately' -- it won't get muddled up
with some other output. If you use cout for debugging
then you can be misled easily.
See
Use larger numbers for more detail or for parts you think work now (but you don't want to remove the DEBUG code just in case you're wrong).
Debuggers can be mesmerizing. I've seen it happen.
Programs will sometimes behave differently in a debugger than in real-life.
It sounds trite but it is true.
Programmers will jump into writing a program or trying to fix a broken one without thinking. You can save yourself much fruitless labour and frustration by planning ahead. The better your plan the less likely your program will be to fail and the more likely you'll be to fix it if it does fail.
My friend Bill didn't do this and spent one-and-a-half
days debugging the wrong part of his program. He was printing
`Hi' or something to show when the flow-of-control had
reached a statement. The problem was that he had two
`Hi's in different parts of the program. He was
seeing the second one -- the first was never reached.
I found the problem in one minute by changing `Hi'
to something more descriptive (`inner for loop' or
something). Bill had to buy me lunch and I didn't even know the
language he was programming in.
If that technique can help a professional programmer save one-and-a-half days, think how the power of debugging can help you.
I was in a computer lab working on a brutal assignment (a recursive BNF parser in Modula 2 -- don't ask, trust me it's not super easy) and the grader comes in every 2 or 3 hours to say that he's changing the assignment (again!). Never mind that is beyond his authority. Suffice it to say that I was stressed and could not get my program to work right.
By the way I was sitting beside a fellow who was also in the class. I'll call him Stu Dent (not his real name). Stu was a rower and had practice at 6 the next morning.
Anyway, for some reason I noticed that the program was not due the next day but rather the day after that. It was late and I was tired. I printed a copy of my program took it with me and left. I slept.
In the morning, I scribbled an outline of a correct program on a piece of paper, while I waited for my cereal to stop making noise. Then, on my printout I crossed off the lines that did not belong and added the ones that were missing. When I got back to school, Stu was at the same terminal -- he'd been there all night, and still didn't have a working program. I typed in my changes and it was perfect. Stu finished his a day later -- a 10% penalty -- and missed rowing practice.
What's the moral of this true story? Not sleep whenever you have a problem but:
I have tested the Javascript version with Netscape Communicator (versions 4.7, 4.76, & 4.78), Opera (version 5.0), Mozilla version 0.9.2.1, Lynx (version 2.7.1ac-0.74) and Internet Explorer (versions 5.00... and 5.50...).
<noscript> tagIf you've had any trouble with the Javascript version then you might prefer the PostScript® or PDF® versions.
Last updated by J. Blustein on 28 April 2002.
This document is copyright by its author, J. Blustein <jamie@csd.uwo.ca>.