|
|
|
|
|
|
|
Bugs, Errors, Mistakes, and Code Rot |
|
|
|
|
|
|
|
|
It has been said that if cities were built, like software is built, the first woodpecker to come along would level civilization. The fact is that all too many commercial programs, from some of the biggest vendors in the business, have bugs. Serious bugs. |
|
|
|
|
|
|
|
|
Although this is true, that does not make it okay; and writing robust, bug-free programs should be the number-one priority of anyone serious about programming. I would argue that the single biggest problem in the software industry is buggy, unstable code. Certainly the biggest expense in many major programming efforts is testing, finding, and fixing bugs. |
|
|
|
|
|
|
|
|
There are a number of discrete kinds of bugs that can trouble a program. The first is poor logic: the program does just what you asked, but you haven't thought through the algorithms properly. The second is syntactic: you used the wrong idiom, function, or structure. These two are the most common, and they are the ones most programmers are on the lookout for. Far harder to find are subtle bugs that pop up only when the user does something unexpected. These little logic bombs can lurk quietly and undisturbed, like a land mine after the war is over. You think everything is okay and then suddenlyBAM!someone steps in the wrong place and your program blows up. |
|
|
|
|
|
|
|
|
Research and real-world experience have shown beyond a doubt that the later in the development process you find a problem, the more it costs to fix it. The least expensive problems or bugs to fix are the ones you manage to avoid creating. The next cheapest are those the compiler spots. The C++ standards force compilers to put a lot of energy into making more and more bugs show up at compile time. |
|
|
|
|
|
|
|
|
Bugs that get compiled but are caught at the first testthose that crash every timeare less expensive to find and fix than those that are flaky and only crash once in a while. |
|
|
|
|
|
|
|
|
A bigger problem than logic or syntactic bugs is unnecessary fragility: your program works just fine if the user enters a number when you ask for one, but it crashes if the user enters letters. Other programs crash if they run out of memory, or if the floppy disk is left out of the drive, or if the modem drops the line. |
|
|
|
|
|
|
|
|
To combat this kind of fragility, programmers strive to make their programs bulletproof. A bulletproof program is one that can handle anything that comes up at runtime, from bizarre user input to running out of memory. |
|
|
|
|
|
|
|
|
It is important to distinguish among bugs. There are those that arise because the programmer made a mistake in syntax. There are also logic errors, which arise because the programmer misunderstood the problem or how to solve it. Finally there are exceptions, which arise because of unusual but predictable problems such as running out of resources (memory or disk space). |
|
|
|
|
|