Chapter 2: Expressions

Writing a computer program eventually boils down to wanting a sequence of statements in the language at hand. How each of those statements is expressed determines in large measure the intelligibility of the whole; no amount of commenting, formatting, or supplementary documentation can entirely replace well expressed statements. After all, they determine what the program actually does. 

• Say what you mean, simply and directly
• Use library functions
• Avoid temporary variables

The fewer temporary variables in a program, the less chance there is that one will not be properly initialized, or that one will be altered unexpectedly before it is used. “Temporary” is a dirty word in programming – it suggests that a variable can be used with less thought than a “normal” (permanent?) one, and it encourages the use of one variable for several unrelated calculations. Both are dangerous practices. 

• Write clearly – Don’t sacrifice clarity for “efficiency.”

Even if the comment about efficiency were true in a particular environment, there is still little justification for using the more obscure mode of expression. (…), we observe simply that a program usually has to be read several times in the process of getting it debugged. The harder it is for people to grasp the intent of any given section, the longer it will be before the program becomes operational. Trying to outsmart a compiler defeats much of the purpose of using one.

• Let the machine do the dirty work

Repeated patterns of code catch the eye when scanning listings. Since the computer is a tool for handling repetitive operations, we should be alerted by such patterns to look for oversights – why didn’t the programmer let the computer do the repeating?

• Replace repetitive expressions by calls to a common function

The ease of later comprehending, debugging, and changing the program will more than compensate for any overhead caused by adding the extra modules.

• Parenthesize to avoid ambiguity
• Choose variable names that won’t be confused
• Avoid the Fortran arithmetic IF
• Avoid unnecessary branches
• Use the good features of a language; avoid the bad ones.
• don’t use conditional branches as a substitute for a logical expression
• Us the “Telephone test” for readability

If someone could understand your code when read aloud over the telephone, it’s clear enough. If not, then it needs rewriting.

Key points:

1. Write Clearly. Try not using “branches” In your code.
2. Be sparing with temporary variables.
3. Be unambiguous. Add parentheses and alter too-similar identifiers to avoid any possibility of misunderstanding
4. Don’t build all of your own tools: use standard library functions. Be sufficient general that your routine can be used in future applications and by other people
5. Make sure the conditional test reads clearly.