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

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

 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

 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

 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

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

 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

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

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

 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

 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

 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

 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

 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

 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

40 years in the making

 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

 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

 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

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