New wine for old bottles
The following rules appear in Kernighan & Plauger’s The Elements of Programming Style, second edition, NY: McGraw-Hill, 1978.
Write clearly – don’t be too clever.
Say what you mean, simply and directly.
- Use library functions.
- Avoid temporary variables.
- Write clearly – don’t sacrifice clarity for ‘efficiency’.
- Let the machine do the dirty work.
- Replace repetitive expressions by calls to a common function.
- Parenthesize to avoid ambiguity.
- Choose variable names that won’t be confused.
- Avoid the Fortran arithmetic
- 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.
Use the ‘telephone test’ for readability.
DO-ENDand indenting to delimit groups of statements.
IF-ELSEto emphasize that only one of two actions is to be performed.
DO-WHILEto emphasize the presence of loops.
- Make your programs read from top to bottom.
IF…ELSE IF…ELSE IF…ELSE …to implement multi-way branches.
- Use the fundamental control flow constructs.
- Write first in an easy-to-understand pseudo-language; then translate into whatever language you have to use.
- Follow each decision as closely as possible with iots associated action.
- Use data arrays to avoid repetitive control sequences.
- Choose a data representation that makes the program simple.
Don’t stop with your first draft.
Modularize. Use subroutines.
- Make the coupling between modules visible.
- Each module should do one thing well.
- Make sure each module hides something.
- Let the data structure the program.
- Don’t patch bad code – rewrite it.
- Write and test a big program in small pieces.
Use recursive procedures for recursively-defined data structures.
Test input for validity and plausibility.
- Make sure input cannot violate the limits of the program.
- Terminate input by end-of-file or marker, not by count.
- Identify bad input; recover if possible.
- Treat end-of-file conditions in a uniform manner.
- Make input easy to prepare and output self-explanatory.
- Use uniform input formats.
- Make input easy to proofread.
- Use freeform input whenever possible.
- Use self-identifying input. Allow defaults. Echo both on output.
Localize input and output in subroutines.
Make sure all variables are initialized before use.
- Don’t stop at one bug.
- Use debugging compilers.
- Initialize constants with
INITIALattributes; 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.
Make it right before you make it faster.
- Keep it right when you make it faster.
- Make it clear before you make it faster.
- Don’t sacrifice clarity for amll gains in ‘efficiency’.
- Let your compiler do the simple optimizations.
- Don’t strain to re-use code; re-organize instead.
- Make sure special cases are truly special.
- Keep it simple to make it faster.
- Don’t diddle code to make it faster – find a better algorithm.
Instrument your programs. Measure before making ‘efficiency’ changes.
Make sure comments and code agree.
- Don’t just echo the code with comments – make every comment count.
- Don’t comment bad code – rewrite it.
- Use variable names that mean something.
- Use statement labels that mean something.
- Format a program to help a reader understand it.
- Indent to show the lgical structure of your program.
- Document your data layouts.
- Don’t over-comment.