Class 25: Preconditions and Postconditions, Revisited

Held Friday, October 11, 2002

Summary

Today we consider an important program design issue: the use of preconditions and postconditions to discuss our structures. We also see how to use the error procedure to report errors.

Related Pages

• Reading on preconditions and postconditions
• Lab on preconditions and postconditions

Assignments

• Homework 5: A Literary Web Service.

Due

• Exam 1

Notes

• I know that many of you had problems on the exam.
  • I'll remind you that you can always elect to take the final as a makeup for an unsatisfactory exam.
  • I'd guess that some of the problems have to do with things you didn't master as well as I'd expected, so we'll spend Monday's class going over the exam. (If the discussion does not resolve problems, you should talk to me individually.)
• Sorry, no other rants today.

Overview

• The need for documentation
• Verifying preconditions
• An example: Sum of squares
• Husk and Kernel programming
• Lab

The Need for Documentation

• While you're currently writing small programs, you will eventually write larger programs, including programs with other people.
  • Experience shows that after about six months, you've forgotten enough of what you've done that you become "other people".
• Every collection of procedures will need documentation giving osme overall structure (and a table of contents).
• Every procedure should be clearly documented as to what it does and what it needs.
• I tend to speak of the six P's. Whenever you write a procedure, you should consider (and often document)
  • The Purpose of the procedure.
  • Any Parameters the procedure takes.
  • Preconditions that must hold for the procedure to work.
  • Postconditions that will hold after the procedure finishes.
  • What the procedure Produces
  • Potential Problems
• You should also document "tricky" parts of your procedures.
• Note that I recommend that you write the documentation before you write the procedure. The six P's give you a way to think carefully about what you want the procedure to do before you think about how, and that thought can often guide you through both creation and debugging.

Robustness; Testing Preconditions

• There are different perspectives on preconditions.
• Some people feel that preconditions are a contract. If the client of a procedure (the code that calls the procedure) doesn't ensure that the preconditions are met, then the procedure is not required to meet the postconditions.
• Others feel that procedures should check their preconditions and respond appropriately.
• Robust programs deal appropriately with incorrect input. Sometimes, the appropriate response is to print an error message and crash.
  • You can use error to do just that.
• If your procedure explicitly tests a precondition, I suggest that you mark the precondition as verified. If your procedure does not test the precondition, please mark the precondition as unverified (even if another procedure will probably generate an error message).

An Example: Sum of Squares

• In class, we'll look at how you might deal with the problem of summing the squares of the values in a list of numbers, both in terms of documentation and in terms of error messages.

Husk and Kernel Programming

• One danger of careful precondition checking is that we do the same thing again and again and again ...
• Good programming style dictates that we try not to do redundant work. If we've verified that a long list contains only numbers, then we know that any sublist contains only numbers.
• One strategy is to break the procedure up into two parts (that is, two procedures). We call them the husk and the kernel.
  • A husk does the checking and then calls the kernel.
  • The kernel does the real work.
• Why these names?
  • The husk protects the kernel
  • The kernel is the good part

Lab

• Do the lab.