Control Structures

1. Control Structures Chapter 14-19

2. Outline • Organizing Straight-Line Code • Using Conditionals • Table-Driven Methods • Control Structures and Complexity

3. Organizing Straight-Line Code • Putting statements and blocks of statements in sequential order - a trivial task? fopen( )fread( )              // fclose( ) should go hereProcessData( )printf( ) fclose( ) • But some organizational subtleties influence code quality, correctness, readability and maintainability • Problem: dependencies

4. Statements in a Specific Order • Statements in which order counts: obvious data = readData(); results = calculateResultsFromData(data); printResults(results); • The 2nd statement depends on the 1st • The 3rd statement depends on the 2nd • Statements in which order counts: less obvious revenue.computeMonthly(); revenue.computeQuarterly(); revenue.computeAnnually();

5. Hidden Dependencies: Example computeMarketingExpense(); computeSalesExpense(); computeTravelExpense(); computePersonnelExpense(); displayExpenseSummary(); • Suppose computeMarketingExpense() initializes the variables that other routines put their data into • It needs to be called before the other routines!

6. Guidelines • Organize code to make dependencies obvious • initializeExpenseData() • Name routines to make dependencies obvious • computeMarketExpense() is misnamed – it does more than compute marketing expenses • computeMarketingExpenseAndInitializeData • Use parameters to make dependencies obvious • initializeExpenseData(expenseData); • computeMarketExpense(expenseData); or expenseData=computeMarketExpense(expenseData);

7. Making Dependencies Obvious: Example initializeExpenseData(expenseData); computeMarketingExpense(expenseData); computeSalesExpense(expenseData); computeTravelExpense(expenseData); computePersonnelExpense(expenseData); displayExpenseSummary(expenseData); • What if initializeExpenseData(expenseData) fails?

8. Guidelines - cont • Check for dependencies with assertions or error-handling code, if the code is critical enough • Constructor may initialize isExpenseDataInitialized to false, then initializeExpenseData sets it to true • Each function depending on expenseData’s initialization can check isExpenseDataInitialized. • The benefits should be weighted against the additional complexity. • It creates new variables and new checking code – all of which create additional possibilities for error. • Document unclear dependencies with comments

9. Making Dependencies Obvious: Example initializeExpenseData(expenseData); if (isExpenseDataInitialized) { computeMarketingExpense(expenseData); computeSalesExpense(expenseData); computeTravelExpense(expenseData); computePersonnelExpense(expenseData); displayExpenseSummary(expenseData); }

10. Statements Whose Order Doesn’t Matter MarketingData marketingData; SalesData salesData; TravelData travelData; travelData.computerQuartly(); salesData.computeQuartly(); marketingData.computeQuartly(); travelData.computerAnually(); salesData.computeAnnually(); marketingData.computeAnnually(); travelData.print(); salesData.print(); marketingData.print(); Bad code that jumps around! How marketingData is calculated? • Start at the last line and track all references back to the first line • Although used in a few places, you have to keep in mind how it is used everywhere between the first and last references

11. Making Code Read from Top to Bottom • Experts agree that top-down order contributes most to readability • Better organization MarketingData marketingData; marketingData.computeQuartly(); marketingData.computeAnually(); marketingData.print(); … • References to each object are kept close together • The # of LOC in which the objects are “live” is small • The code now looks as if it could be broken into separate routines for marketing, sales, and travel data.

12. Grouping Related Statements • Statements are related because they • operate on the same data, • perform similar tasks, or • depending on each other’s being performed in order

13. If the code is well organized into groups, boxes drawn around related sections don't overlap. They might be nested If the code is organized poorly, boxes drawn around related sections overlap

14. Using Conditionals • Put the normal case after the if rather than after the else if(){ normal case; } else{ unnormal case } • Don't use NULL then clauses

15. Can You Improve This Code? if ( ( (‘a’<=inputChar) && (inputChar <=‘z’)) || ( (‘A’<=inputChar) && (inputChar <=‘Z’))) { charType = CharacterType.Letter; } else if ( (inputChar==‘ ‘) ||(inputChar == ‘,’) || (inputChar==‘.‘) || (inputChar==‘!‘) || (inputChar==‘(‘) || (inputChar==‘)‘) || (inputChar==‘:‘) || (inputChar==‘;‘) || (inputChar==‘?‘) || (inputChar==‘-‘)) { charType = CharacterType.Punctuation; } else if ((‘0’<=inputChar) && (inputChar <=‘9’)) { charType = CharacterType.Digit; }

16. Simplify complicated tests with boolean function calls

17. Put the most common cases first

18. Make sure that all cases are covered • Code a final else clause with an error message or assertion to catch cases you didn't plan for.

19. Replace if-then-else chains • with other constructs if your language supports them

20. Can You Improve This Code? if (month==1) days =31; else if (month==2) days = 28; else if (month==3) days = 31; … else if (month == 12) days = 31; • Leap year: more complicated

21. Controlling loop

23. Guidelines

30. Can You Improve This Code? • TaxReturn.java: 1992 tax return • Filing status: single, married (jointly/separately) • Cutoffs/rates

31. Table-Driven Methods • What is a table-driven method? • A scheme that allows you to look up info in table • Rather than using logic statements (if and case) to figure it out • Why? • In simple cases, logic statements are easier and more direct • As the logic chain becomes more complex, tables become increasingly attractive

33. The CharacterType Example • Use a lookup table • Store the type of each character in an array that’s accessed by character code • charType = charTypeTable[inputChar]; • Assume charTypeTable has been set up earlier • Put your program’s knowledge into its data rather than into its logic (if tests)

34. The Days-in-Month Example int daysPerMonth[] = {31,28, 31, 30,…, 31}; days = daysPerMonth[month-1]; • Leap year days = daysPerMonth[month-1] + leapYearIndex(); // 0/1

35. Stair-Step Access

36. Stair-Step Access Tables • Entries in a table are valid for ranges of data rather than for distinct data points • Example <=100.0 A <90.0% B <75.0% C <65.0% D <50.0% F • Table structure?

37. Example double rangeLimit[] = {50.0, 65.0, 75.0, 90.0, 100.0}; String grade[] = {“F”, “D”, “C”, “B”, “A”}; int maxGradeLevel = grade.length -1; int gradeLevel = 0; String studentGrade = “A”; while (studentGrade==“A” && gradeLevel<maxGradeLevel) { if (studentScore>rangeLimit[gradeLevel] studentGrade = grade[gradeLevel]; gradeLevel = gradeLevel+1; }

38. Try it out!

39. Boolean Expression

40. Boolean Expression – cont’ • I ain't not no undummy

42. Boolean Expression – cont’ • Apply DeMorgan's Theorems to simplify boolean tests with negatives

43. Boolean Expression – cont’ • Using Parentheses to Clarify Boolean Expressions

44. Boolean Expression – cont’ • Short-circuit evaluation • if the first operand of the and is false, the second isn't evaluated because the whole expression would be false anyway. if ( SomethingFalse && SomeCondition ) ... • Only SomethingFalse will be evaluated • Evaluation stops as soon as SomethingFalse is identified as false

45. Boolean Expression – cont’ • using number-line ordering for boolean tests

46. Subtleties • Watch the endpoints • Consider using a binary search rather than a sequential search for a larger list • Consider using indexed access

47. Control Structures and Complexity • Three Components of Structured Programming • Sequence, Selection, Iteration • Any control flow can be created • Use of any other structure should be viewed with a critical eye: break, continue, return, throw-catch • Control structures are a big contributor to overall program complexity • Poor use of control structures increases complexity. • Programming complexity • Number of mental objects you have to keep in mind simultaneously in order to understand a program

48. How to Measure Complexity? • McCabe’s Cyclomatic Number • C = E-N+2 E (number of edges), N (number of nodes) • C = R+1, R is the number of legitimate regions • C = D+1, D is the number of primitive decisions

49. How to Measure Complexity • McCabe’s Decision Points • Start with 1 for the straight path through the routine • Add 1 for each of the following keywords, or their equivalence: if, while, repeat, for, and, or • Add 1 for each case in a case statement • Example if ((status==Success) && done) || (!done && (numLines >=maxLines))) … • 5 decision points

50. Decision Points and Complexity • 0-5: probably fine • 6-10: start to think about ways to simplify • 10+: brake part of the routine • It just moves the decision points around; doesn’t reduce the overall complexity • Reduces the amount of complexity you have to deal with at any ONE time • 10 isn’t an absolute limit – use it as a warning flag • Don’t use it as an inflexible rule • It might be foolish to break up a case statement with many cases