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 expression Equivalent Expression

not A and not B not (A or B)

not A and B not (A or not B)

A and not B not (not A or B)

A and B not (not A or not B)

not A or not B not (A and B)

not A or B not (A and not B)

A or not B not (not A and B)

A or B not (not A and not B)

DeMorgan’s Theorem