thursday: › team presentations › risk assessment and project plan due 11:55 pm friday: › help...
TRANSCRIPT
Thursday:› Team Presentations› Risk Assessment and project plan due
11:55 pm Friday:
› Help on coding/testing Monday:
› HW 5 due, 11:55 pm
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
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
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