Class 14: Preconditions and postconditions

Held Monday, September 18, 2000

Summary

Today we consider an important program design issue: the use of preconditions and postconditions to discuss our structures.

Notes

• Today's lab: Preconditions and postconditions
• Tomorrow's reading: Pairs and pair structures
• Even though I promised you a quiz for today, I've decided against holding one.
• Don't forget today's brown-bag lunch.
• Tutors are available for CSC151.
  • No stigma attached. About a third of the CSC152 students have tutors (at least when I teach it).
  • Talk to Katherine McClelland in the Math Lab.

Overview

• Writing documentation
• Preconditions and postconditions

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.

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.

An Example: Sum of Squares

• To be done in class.

Husk and Kernel Programming

• Avoid rechecking the same thing again and again and again ...
• A husk does the checking and then calls the kernel.
• The kernel does the real work.