Held Monday, September 18, 2000
Today we consider an important program design issue: the use of preconditions
and postconditions to discuss our structures.
- 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
- 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.
- Writing documentation
- Preconditions and postconditions
- 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.
- 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
- 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.
- 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.