CSC151.02, Class 22: Preconditions and Postconditions, Revisited

Overview:
* Exam 1 not graded.  Sorry.
* New dorm dedication tonight!
* We may have a prospective named Rich Hubbard visiting.  His "friend" says to throw things at him.
* Reading for Monday (finally): Local Bindings
* Reminder: Numeric recursion lab due Tuesday.  Email to me and guhaarju.
* Note that the code we developed on Monday is linked from today's outline.

Topics:
* What are preconditions and postconditions?  Why have them?
* Should we check them?
* What is Husk and Kernel programming?  Why bother?
* Lab
* Reflection

/What are preconditions and postconditions?  Why have them?/
* They make it easier to talk to Pete.  [No]
* Documentation in general helps you remember what you did.
* Lets other people modify or *use* your programs.
* Sam likes to fail people who don't write preconditions and postconditions.
* If you write your preconditions and postconditions *first*, you have a better sense of what your procedure should do, and therefore how to write it.

/Debate among software designers: Check or not check preconditions?/
* User-friendly if you check them.
* Slow to check them.

/One solution: Husk-and-Kernel Programming/
* What is it?  A corny way to program.
* The husk of an ear of corn protects the corn.
* The kernel of an ear of corn is the valuable part of the corn.
* The husk of a husk-and-colonel program is the protection
* The kernel of a husk-and-kernel program is the "wicked important part"

The husk checks the preconditions.
The kernel does the work.

An example, square

/Attempt the Lab/

/Reflections/
* I am so proud that many of you decided that you'd learn more from rewriting all-real? than copying and pasting.