Compartilhar via

Programming Proverbs

  • Artigo

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

  • Anonymous
    January 19, 2007
    Walking On Water and Writing a Software is easy, if the Water and Specifications are FROZEN

  • Anonymous
    January 19, 2007
    The comment has been removed

  • Anonymous
    January 22, 2007
    Write automated tests.

  • Anonymous
    January 22, 2007
    Number 3: It's interesting to note that IntelliSense encourages a bottom-up approach.  See http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html 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.

  • Anonymous
    January 23, 2007
    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.

  • Anonymous
    May 12, 2007
    When ever programming teachers get together one of the debates that often starts up is between using

  • Anonymous
    June 03, 2007
    In some ways I think this is one of those proverbs that was more important back in the days when batch

  • Anonymous
    July 05, 2007
    This proverb is a corollary to the last post in this series . While getting the program correct and the

  • Anonymous
    July 08, 2007
    I've been telling students and others that " reading the manual is the shortcut " for years

  • Anonymous
    July 10, 2007
    The comment has been removed

  • Anonymous
    July 12, 2007
    The statement "Don't be afraid to start over" seems obvious to the breed of programmer