Everyone has had a program crash. A standard story is that you were typing in a paper when, all of a sudden, your word processor crashed. You had forgotten to save, and you had to start all over again. Old versions of Microsoft Windows used to crash more often than they should have, showing the dreaded “blue screen of death.” Usually, your computer shows some cryptic error message when a program crashes.
What happened in each case is that the people who wrote the program told the computer to do something it couldn’t do: open a file that didn’t exist, perhaps, or keep track of more information than the computer could handle, or maybe repeat a task with no way of stopping other than by rebooting the computer. (Programmers don’t mean to make these kinds of mistakes; they are just part of the programming process.)
How Bugs Became “Bugs” | |
|---|---|
| | In 1947, engineers working on the Harvard Mark II computer found a moth stuck in a relay. They taped it into their logbook with the note: “First actual case of bug being found.” The term bug had been used earlier in engineering, but this moment gave it a lasting place in computing lore. |
Worse, some bugs don’t cause a crash; instead, they give incorrect information. (This is worse because at least with a crash, you’ll notice that there’s a problem.) As a real-life example of this kind of bug, the calendar program used by one of the authors contains an entry for a friend who was born in 1978. That friend, according to the calendar program, had his 5,875,552nd birthday this past February. Bugs can be entertaining, but they can also be tremendously frustrating.
Every piece of software that you can buy has bugs in it. Part of your job as a programmer is to minimize the number of bugs and to reduce their severity. To find a bug, you must first identify where you provided incorrect instructions. Then, you need to determine the correct instructions and update the program without introducing additional bugs.
Every time you receive a software update for a program, it is for one of two reasons: new features have been added to the program, or bugs have been fixed. It’s always a game of economics for the software company. Are there few enough bugs, and are they minor enough or infrequent enough for people to pay for the software?
In this book, we’ll show you some fundamental techniques for finding and fixing bugs, as well as for preventing them in the first place.