Geek Logbook

Tech sea log book

The elements of programming style: Common Blunders

Chapter 6: Common Blunders

A major concern of programming is making sure that a program can defend against bad data. But even with correct data, there is no guarantee that a program will work. In this chapter we will discuss other aspects of making software reliable.

  • Make sure all variables are initialized before use
  • Don’t stop at one bug
  • Usi debbuging compilers
  • Initialize constants with DATA statements or INITIAL attributes; initialize variables with executable code.
  • Watch out for off-by-one errors
  • Take care to branch the right way on equality
  • Avoid multiple exits from loops
  • Make sure your code “does nothing” gracefully
  • Test programs at their boundary values
  • program defensively
  • 10.0 times 0.1 is hardly ever 1.0
  • Don’t compare floating point numbers just for equality

Let us summarize the main lessons of this chapter. Remember that the errors that we have shown are by no means all that can happen; they represent the common ones.

(1)  Initialize variables before using them. Be sure that variables in subroutines and inner loops are properly reset between successive uses. Set constants at compile time and variables at run time. If a debugging compiler is available to check for initialization errors, use it. 

(2) Watch for off-by-one errors. Be sure that things are done the right number of times, and that comparison tests branch the right way on equality. 

(3) Check that array references do not go out of bounds. Again, if subscript-range checking is available from your compiler, use it.

 (4)  Avoid multiple exits from a loop. Keep exit tests close together and as near the top as possible. 

(5) Test your program at its internal boundaries. This should be done before the program is run, and as a running check. Ask whether each loop might be performed zero times under some circumstances, and if you are writing in Fortran, augment DO statements with IF’s if they may have to be skipped. 

(6) Program defensively. Be aware of the kinds of things that could go wrong, and add code to check for them.

 (7)  Do not count with floating point numbers. Do not expect fractional floating point values to obey the familiar laws of arithmetic – they do not.

Leave a Reply

Your email address will not be published. Required fields are marked *.

You may use these <abbr title="HyperText Markup Language">HTML</abbr> tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>