Economics has been dubbed “the dismal science,” but there’s nothing so dismal as debugging a computer program that’s malfunctioning.
Before you can fix a computer program, you usually need to know the why and how of its malfunction. I’ve spent many frustrating hours trying to understand why a program isn’t working properly.
If things really go wrong, in the process of fixing the program I make things worse. Usually, this means I don’t understand the problem well enough. Be this as it may, it’s human to attempt to shortcut tedious tasks— but doing so often leads to long delays!
Anyhow, if I attempt to fix a program without really first understanding the problem, I might try something and then run the program again to see if the fix worked. If I’m lucky, the fix worked! But, if not, I’m often hit with a flash of inspiration and try another “quick fix.” By the time I’ve iterated this process half a dozen times, I may no longer even be able to get back to where I started—and the program still doesn’t work right!
The moral of this sordid little tale of woe and bad working habits is that debugging a computer program is one place in which it pays to work in an organized fashion. Be calm, cool, and collected, and keep notes so that you can retrace your steps.
Perhaps the most important habit when debugging is to be methodical. It helps to think things through as though you were the computer, processing the software program. What could have caused the aberrant results? What are the possibilities? How can you rule them out one by one?
As I said in the first chapter of this book, to successfully program you must learn to think like a computer. Nowhere is this truer than in debugging.
The goal of this chapter is to provide you with the tools you need to deal with bugs. To that end, I’ll provide an overview of the different categories of bugs you’ll encounter: syntax errors, runtime errors, and logical errors. This material is language independent and applies to all programming environments. I’ll also briefly describe some of the most common kinds of errors.
Testing a program is a vital step in making sure that it’s bug free and in uncovering latent defects. I’ll provide some guidelines for testing your programs.
Supposedly, the use of the word bug to mean a problem or flaw in a computer program comes from a literal insect that was creating havoc inside a 1950s computer. Admiral Grace Hopper, an early programmer and one of the creators of the language COBOL, is said to have discovered that a moth was causing a vacuum tube monster to malfunction, hence the term bug.
These days, a bug refers to any error, problem, or flaw that causes computer software or hardware to malfunction.
In actual historical fact, bug was used long before the invention of the computer to mean a glitch or problem in an industrial or scientific process. (Thomas Edison is on record as having used the term this way.) However, Admiral Hopper is probably the first to use the term in connection with a computer (if the moth causing her problem had been preserved, it would no doubt be a valuable collectible today!).