The Elements of Programming Style
The look brings a lot of timeless wisdom, but unfortunately the examples are written in Fortran. 🙁
video
Video of a talk from Brian Kernighan, 2009-07-13. https://youtu.be/8SUkrR7ZfTA
Lessons
From wikipedia
- Write clearly – don't be too clever.
- Say what you mean, simply and directly.
- Use library functions whenever feasible.
- Avoid too many temporary variables.
- Write clearly – don't sacrifice clarity for efficiency.
- Let the machine do the dirty work.
- Replace repetitive expressions by calls to common functions.
- Parenthesize to avoid ambiguity.
- Choose variable names that won't be confused.
- Avoid unnecessary branches.
- If a logical expression is hard to understand, try transforming it.
- Choose a data representation that makes the program simple.
- Write first in easy-to-understand pseudo language; then translate into whatever language you have to use.
- Modularize. Use procedures and functions.
- Avoid gotos completely if you can keep the program readable.
- 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 plausibility and validity.
- Make sure input doesn't violate the limits of the program.
- Terminate input by end-of-file marker, not by count.
- Identify bad input; recover if possible.
- Make input easy to prepare and output self-explanatory.
- Use uniform input formats.
- Make input easy to proofread.
- Use self-identifying input. Allow defaults. Echo both on output.
- Make sure all variables are initialized before use.
- Don't stop at one bug.
- Use debugging compilers.
- Watch out for off-by-one errors.
- Take care to branch the right way on equality.
- Be careful if a loop exits to the same place from the middle and the bottom.
- Make sure your code does "nothing" gracefully.
- Test programs at their boundary values.
- Check some answers by hand.
- 10.0 times 0.1 is hardly ever 1.0.
- 7/8 is zero while 7.0/8.0 is not zero.
- Don't compare floating point numbers solely for equality.
- Make it right before you make it faster.
- Make it fail-safe before you make it faster.
- Make it clear before you make it faster.
- Don't sacrifice clarity for small gains in efficiency.
- Let your compiler do the simple optimizations.
- Don't strain to re-use code; reorganize 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 the reader understand it.
- Document your data layouts.
- Don't over-comment