Programming Proverbs

A recent blog post by Josh Ledgard reminded me of a book that had a great influence in my early programming days. The books was Programming Proverbs by Henry Ledgard and I still have my copy. It's one of the few computer books I bought in the mid 1970's that still has some relevance.  The code examples are in ALGOL, FORTRAN and BASIC but the ideas apply to most all programming languages. Dr. Ledgard also wrote related books specifically for C, COBOL (I have that one), FORTRAN (I used to have that one but I can't find it) and PASCAL. It was quite the series.

I've been re-reading the book since last week and I am thinking about writing a series of posts about each proverb. I'm interested in seeing some discussion about how each one holds up over time. The book is over 30 years old and there is a lot we have learned about programming in that time. Or is there? Other than Object Oriented Programming what's new? Are programs today less buggy than they were thirty years ago? Actually I think they are worse many times. Perhaps we should bring more of these proverbs to people's attention? Of course many of them are being brought up but are people really paying attention? Let's discuss it.

What is the list you ask? Well here it is.

  1. Define the problem completely
  2. Think first, Program later
  3. Use the top-down approach
  4. Beware other approaches
  5. Construct the program in logical units
  6. Use procedures {methods}
  7. Avoid unnecessary GOTO's
  8. Avoid side effects
  9. Get the syntax correct now, not later
  10. Use good mnemonic names
  11. Use intermediate variables properly
  12. Leave loop variables alone
  13. Do not recompute constants within a loop
  14. Avoid implementation-dependent features
  15. Avoid tricks
  16. Build in debugging techniques
  17. Never assume the computer assumes anything
  18. Use comments
  19. Prettyprint - format your code so that it looks nice
  20. Provide good documentation
  21. Hand-check the program before running it
  22. Get the program correct before trying to provide good output
  23. When the program is correct, produce good output
  24. Re-read the manual
  25. Consider another language
  26. Don't be afraid to start over

What do you think of this list? Anything you would add or drop?