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.
- Define the problem completely
- Think first, Program later
- Use the top-down approach
- Beware other approaches
- Construct the program in logical units
- Use procedures {methods}
- Avoid unnecessary GOTO's
- Avoid side effects
- Get the syntax correct now, not later
- Use good mnemonic names
- Use intermediate variables properly
- Leave loop variables alone
- Do not recompute constants within a loop
- Avoid implementation-dependent features
- Avoid tricks
- Build in debugging techniques
- Never assume the computer assumes anything
- Use comments
- Prettyprint - format your code so that it looks nice
- Provide good documentation
- Hand-check the program before running it
- Get the program correct before trying to provide good output
- When the program is correct, produce good output
- Re-read the manual
- Consider another language
- Don't be afraid to start over
What do you think of this list? Anything you would add or drop?