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?

Comments (11)
  1. koolraagaa says:

    Walking On Water and Writing a Software is easy, if the Water and Specifications are FROZEN

  2. Anthony Tarlano says:

    1. Explicit is better then implicit

    2. Practicality beats purity

    3. Readability counts

    4. When in doubt, use brute force

    5. Simplicity, Clarity, Generality form the bedrock of good software

  3. Ben Fulton says:

    Write automated tests.

  4. Eric Pepke says:

    Number 3: It’s interesting to note that IntelliSense encourages a bottom-up approach.  See

    Number 21: This was all the rage when programs took 10 minutes to compile.  It’s still a good idea for discipline but probably far less important.

    Number 13: Any compiler worth its salt is going to optimize these out.

    Numbers 25 and 26: Impractical in most cases.

    The most interesting thing about what has happened in CS over the past quarter century is that Fred Brooks’ 1-3-9 rule is now completely inverted.  He said that it costs nine times as much to make a general, interoperable system than an ad hoc one.  Now, it is far more costly to make an ad hoc system than a general, interoperable one.  This is mostly due to standards, such as XML, HTML, Soap, Unicode, the DOM (especially in .Net 2.0), XSLT, XPath, etc.

  5. AlfredTh says:

    Interesting comment about IntelliSense encouraging a bottom-up approach. I think that is true if you start with programming and not with design. What I mean by that is that some people create their design in code rather than working out the full design before starting to code. I think that if you create a design using a top down approach it takes longer to get to the building blocks. that is frustrating to many, especially students, but in the long run results in a much better design.

    With a complete design in place one does know what the little blocks of code will be at least from the standpoint of names and interfaces. Creating those little blocks early on in the programming is fine as long as the design is complete.

  6. When ever programming teachers get together one of the debates that often starts up is between using

  7. In some ways I think this is one of those proverbs that was more important back in the days when batch

  8. This proverb is a corollary to the last post in this series . While getting the program correct and the

  9. I've been telling students and others that " reading the manual is the shortcut " for years

  10. What's that old line about if all you have is a hammer all your problems look like nails? There are

  11. The statement "Don't be afraid to start over" seems obvious to the breed of programmer

Comments are closed.

Skip to main content