1. PRAGMATIC PARANOIA Steven Hadfield & Anthony Rice

2. You can’t write perfect software  Accept it  Nobody else writes it either  Be defensive about other people’s code  Play it safe

3. Design by Contract  Developed by Bertrand Meyer (Eiffel)  Use contracts to force both parties into an agreement: caller and routine  Each party is expected to uphold their end of the deal  Preconditions, postconditions, and class invariants

4. Preconditions  What the caller guarantees will be passed to the routine  The routine’s requirements  It’s up to the calling code to make sure that the requirements are kept

5. Postconditions  What the routine guarantees to return  How the world should be after the routine is done  Lazy code: require a lot, promise little in return

6. Class invariants  Conditions that should always be true from caller’s perspective  Routine possibly allowed to change it temporarily while working, but should return to previous state  Things that the routine is not allowed to change  Applies to all methods in a class

7. Designing with Contracts  It’s a design technique  Directly supported by some languages  Handy if compiler can do it, but not necessary  Assertions – partially emulate DBC  Use preprocessors for languages without  Messy and not as good, but helpful  Can be dynamically generated  Rejected and/or negotiated

8. Invariants  Also applies at lower levels  Loop invariant  Making sure something is true before and during a loop  Semantic invariants  Central to the purpose of a task  Should be clear and unambiguous

9. Dead Programs Tell No Lies  If a program is going to crash, do it early  Crash with class  Provide useful information  If the impossible happens, die as soon as possible  Everything after the impossible happens is suspect

10. Assertive Programming  This can never happen…  “This code will not be used 30 years from now, so two- digit dates are fine”  “This application will never be used abroad, so why internationalize it?”  “count can’t be negative”  “This printf can’t fail”

11. Assertions  If it can’t happen, use assertions to ensure that it won’t  Don’t use assertions as error handling, they should just be used to check for things that should never happen.  Void writeString(char *string){ assert(string != NULL);  Never put code that should be executed into as assert.

12. Leave Assertions Turned On  Misunderstanding:  Since they check for things that should never happen, the are only triggered by a bug in the code. They should be turned off when shipped to make the code run faster.

13. Leave Assertions Turned On  You cannot assume that testing will find all the bugs.  Your program runs in a dangerous world.  Your first line of defense is checking for any possible error, and your second is using assertions to try to detect those you missed.

14. Assertions and Side Effects  Instead of:  While (iter.hasMoreElements()) { Test.ASSERT(iter.nextElement() != null); Object obj = iter.nextElement();  Do:  While (iter.hasMoreElements()) { Object obj = iter.nextElement(); Test. ASSERT(obj != null);

15. When to Use Exceptions  Checking for every possible error can lead to some pretty ugly code.  If the programming language supports exceptions, you can use try catch loops to make the code much easier to read.

16. What is Exceptional?  Exceptions should be reserved for unexpected events.  They should rarely be used as the programs normal flow.

17. Use Exceptions for Exceptional Programs  An exception represents an immediate, nonlocal transfer of control.  Using exceptions as part of normal processing will give you all the readability and maintainability problems of spaghetti code.

18. Error Handlers Are an Alternative  Error Handlers are routines that are called when an error is detected.  These routines can handle a specific category of errors.

19. How to Balance Resources  Finish What You Start  Many developers have not consistent plan for dealing with resource allocation and deallocation.  The routine or object that allocates a resource should be responsible for deallocating it.

20. Nest Allocations  The basic pattern for resource allocation can be extended for routines that need more than one resource at a time.  Deallocate resources in the opposite order in which you allocate them.  When allocating the same set of resources in different places in your code, always allocate them in the same order.

21. Objects and Exceptions  Encapsulation of resources in classes  Instantiate that class when you need a particular resource type.

22. When You Can’t Balance Resources  Commonly found in programs that use dynamic data structures.  When you deallocate the top-level data structure:  Top-level structure responsible for substructures.  Top-level structure is simply deallocated.  Top-level structure refuses to deallocate itself if it contains substructures.  Choice depends on individual data structure.

23. Checking the Balance  Produce wrappers for each resource, and keep track of all allocations and deallocations.  When program logic says resources will be in a certain state you can use the wrappers to check it.