Bugs, Errors, Mistakes, and Code Rot ................................................................
It is rare for a real-world-sized program not to have some sort of error, or bug. The big-
ger the program, the more likely there will be bugs. In fact, in larger programs, it is often
the case that many bugs actually “get out the door” and into final, released software. That
this is true does not make it okay. Making robust, bug-free programs should be the num-
ber-one priority of anyone serious about programming.
The single biggest problem in the software industry is buggy, unstable code. One of the
biggest expenses in many major programming efforts is testing and fixing. The person
who solves the problem of producing good, solid, bulletproof programs at low cost and
on time will revolutionize the software industry.
A number of discrete kinds of errors 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.
Research and real-world experience have shown that the later in the development process
you find a logic 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 spotted by
the compiler. The C++ standards force compilers to put a lot of energy into making more
and more bugs show up at compile time.
Errors that get compiled in your program, but are caught at the first test—those that crash
every time—are less expensive to find and fix than those that are flaky and only crash
once in a while.
A more common runtime problem than logic or syntactic bugs is 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, if the floppy disk is
left out of the drive, or if an Internet connection is lost.
To combat this kind of fragility, programmers strive to make their programs bulletproof.
A bulletproofprogram 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 between bugs, which arise because the programmer made a
mistake; logic errors, which arise because the programmer misunderstood the problem or
how to solve it; and exceptions, which arise because of unusual but predictable problems
such as running out of resources (memory or disk space).716 Day 20