2.  Thursday: › Team Presentations › Risk Assessment and project plan due 11:55 pm  Friday: › Help on coding/testing  Monday: › HW 5 due, 11:55 pm

3.  Case Statements  Loops  Unusual control structures  Go-to debate  General control issues

5.  Nominal path through first › Then write unusual cases  Check branches › > instead of >= is analogous to off-by-one  Put the normal case after the if  Follow the if clause with a meaningful statement

6.  Consider the else clause › GM analysis: 50-80% of if statements should have an else clause  Test the else clause for correctness  Check for reversal of the if and else clauses

7.  Simplify complicated test with boolean function calls  Put the most common cases first  Make sure all cases are covered  Replace with other constructs, if supported

8.  Order cases alphabetically or numerically  Normal case first  Order cases by frequency

9.  Keep the actions of each case simple  Don’t make up phony variables  Use the default clause only to detect legitimate defaults  Avoid dropping through

12.  Enter only from one location  Put initialization code directly before the loop  Use while( true ) for infinite loops  Prefer for loops when appropriate

13.  Use brackets  Avoid empty loops  Keep loop-housekeeping at either the beginning or the end  Make each loop perform only one function

14.  Assure yourself that the loop ends  Make loop-termination conditions obvious  Don’t mess with the loop index to make the loop terminate  Avoid code that depends on the loop index’s final value  Consider using safety counters

15.  Consider using break statements over boolean flags  Be wary of loops with lots of breaks › January 15, 1990: NYC’s phone system halted for 9 hrs do to an extra break  Use continue for tests at the top of a loop  Use the labeled break structure if supported  Use break and continue only with caution

16.  Use ordinal or enumerated types for limits on both arrays and loops  Use meaningful variable names to make nested loops readable  Use meaningful names to avoid loop- index cross-talk  Limit the scope of loop-index variables to the loop itself

17.  Short enough to view all at once  Limit nesting to three levels  Move loop innards of long loops into routines  Make long loops especially clear

19.  Use a return when it enhanced readability  Use guard clauses (early returns/exits) to simplify complex error processing  Minimize the number of returns in each routine

20.  Make sure the recursion stops  Use safety counters to prevent infinite recursion  Limit recursion to one routine › Cyclic: A calls B calls C calls A  Keep an eye on the stack

21. 40 years in the making

22.  Higher-quality without › “Go To Statement Considered Harmful”, by Edsger Dijkstra, Communications of the ACM, March 1968  Hard to format  Defeats complier optimizations  Not necessarily small or faster › “Structured Programming with go to Statements” by Donald Knuth  Violation of the principle that code should flow from top to bottom  Many modern languages (like Java) don’t even have gotos

23.  Careful use in specific circumstances rather than indiscriminant use › No loops in Fortran  Can eliminate duplicate code  Useful in a routine that allocates resources, performs operations on those resources, and then deallocates the resources  Smaller and faster › See again Knuth’s article  Incorporated into many modern languages › Including Ada

25.  Compare boolean values to true and false implicity  Break complicated tests into partial test with new boolean variables  Move complicated expressions into boolean functions  Use decision tables to replace complicated conditions

26. Initial expressionEquivalent Expression not A and not Bnot (A or B) not A and Bnot (A or not B) A and not Bnot (not A or B) A and Bnot (not A or not B) not A or not Bnot (A and B) not A or Bnot (A and not B) A or not Bnot (not A and B) A or Bnot (not A and not B) DeMorgan’s Theorem