Presentation is loading. Please wait.

Presentation is loading. Please wait.

 2006 Pearson Education, Inc. All rights reserved. 1 6 6 Control Statements: Part 2.

Similar presentations


Presentation on theme: " 2006 Pearson Education, Inc. All rights reserved. 1 6 6 Control Statements: Part 2."— Presentation transcript:

1  2006 Pearson Education, Inc. All rights reserved. 1 6 6 Control Statements: Part 2

2  2006 Pearson Education, Inc. All rights reserved. 2 Not everything that can be counted counts, and not every thing that counts can be counted. — Albert Einstein Who can control his fate? — William Shakespeare The used key is always bright. — Benjamin Franklin

3  2006 Pearson Education, Inc. All rights reserved. 3 Every advantage in the past is judged in the light of the final issue. — Demosthenes Intelligence …is the faculty of making artificial objects, especially tools to make tools. — Henri Bergson

4  2006 Pearson Education, Inc. All rights reserved. 4 OBJECTIVES In this chapter you will learn:  The essentials of counter-controlled repetition.  To use the for and do...while repetition statements to execute statements in an application repeatedly.  To understand multiple selection using the switch selection statement.  To use the break and continue program control statements to alter the flow of control.  To use the logical operators to form complex conditional expressions in control statements.

5  2006 Pearson Education, Inc. All rights reserved. 5 6.1Introduction 6.2Essentials of Counter-Controlled Repetition 6.3 for Repetition Statement 6.4Examples Using the for Statement 6.5 do…while Repetition Statement 6.6 switch Multiple-Selection Statement 6.7 break and continue Statements 6.8Logical Operators 6.9Structured Programming Summary 6.10(Optional) Software Engineering Case Study: Identifying Objects’ States and Activities in the ATM System 6.11Wrap-Up

6  2006 Pearson Education, Inc. All rights reserved. 6 Common Programming Error 6.1 Because floating-point values may be approximate, controlling loops with floating- point variables may result in imprecise counter values and inaccurate termination tests.

7  2006 Pearson Education, Inc. All rights reserved. 7 Error-Prevention Tip 6.1 Control counting loops with integers.

8  2006 Pearson Education, Inc. All rights reserved. 8 Outline WhileCounter.cs

9  2006 Pearson Education, Inc. All rights reserved. 9 Good Programming Practice 6.1 Place blank lines above and below repetition and selection control statements, and indent the statement bodies to enhance readability.

10  2006 Pearson Education, Inc. All rights reserved. 10 Software Engineering Observation 6.1 “Keep it simple” is good advice for most of the code you will write.

11  2006 Pearson Education, Inc. All rights reserved. 11 Outline ForCounter.cs

12  2006 Pearson Education, Inc. All rights reserved. 12 Common Programming Error 6.2 Using an incorrect relational operator or an incorrect final value of a loop counter in the loop-continuation condition of a repetition statement causes an off-by-one error.

13  2006 Pearson Education, Inc. All rights reserved. 13 Good Programming Practice 6.2 Using the final value in the condition of a while or for statement with the <= relational operator helps avoid off-by-one errors. For a loop that prints the values 1 to 10, the loop-continuation condition should be counter <= 10, rather than counter < 10 (which causes an off-by-one error) or counter < 11 (which is correct). Many programmers prefer so-called zero-based counting, in which to count 10 times, counter would be initialized to zero and the loop- continuation test would be counter < 10.

14  2006 Pearson Education, Inc. All rights reserved. 14 Fig. 6.3 | for statement header components.

15  2006 Pearson Education, Inc. All rights reserved. 15 Common Programming Error 6.3 Using commas instead of the two required semicolons in a for header is a syntax error.

16  2006 Pearson Education, Inc. All rights reserved. 16 Common Programming Error 6.4 When a for statement’s control variable is declared in the initialization section of the for ’s header, using the control variable after the for ’s body is a compilation error.

17  2006 Pearson Education, Inc. All rights reserved. 17 Performance Tip 6.1 There is a slight performance advantage to using the prefix increment operator, but if you choose the postfix increment operator because it seems more natural (as in a for header), optimizing compilers will generate MSIL code that uses the more efficient form anyway.

18  2006 Pearson Education, Inc. All rights reserved. 18 Good Programming Practice 6.3 In many cases, the prefix and postfix increment operators are both used to add 1 to a variable in a statement by itself. In these cases, the effect is exactly the same, except that the prefix increment operator has a slight performance advantage. Given that the compiler typically optimizes your code to help you get the best performance, use the idiom (prefix or postfix) with which you feel most comfortable in these situations.

19  2006 Pearson Education, Inc. All rights reserved. 19 Common Programming Error 6.5 Placing a semicolon immediately to the right of the right parenthesis of a for header makes that for ’s body an empty statement. This is normally a logic error.

20  2006 Pearson Education, Inc. All rights reserved. 20 Error-Prevention Tip 6.2 Infinite loops occur when the loop-continuation condition in a repetition statement never becomes false. To prevent this situation in a counter- controlled loop, ensure that the control variable is incremented (or decremented) during each iteration of the loop. In a sentinel-controlled loop, ensure that the sentinel value is eventually input.

21  2006 Pearson Education, Inc. All rights reserved. 21 Error-Prevention Tip 6.3 Although the value of the control variable can be changed in the body of a for loop, avoid doing so, because this practice can lead to subtle errors.

22  2006 Pearson Education, Inc. All rights reserved. 22 Fig. 6.4 | UML activity diagram for the for statement in Fig. 6.2.

23  2006 Pearson Education, Inc. All rights reserved. 23 Common Programming Error 6.6 Not using the proper relational operator in the loop-continuation condition of a loop that counts downward (e.g., using i = 1 in a loop counting down to 1) is a logic error.

24  2006 Pearson Education, Inc. All rights reserved. 24 Outline Sum.cs

25  2006 Pearson Education, Inc. All rights reserved. 25 Good Programming Practice 6.4 Limit the size of control statement headers to a single line if possible.

26  2006 Pearson Education, Inc. All rights reserved. 26 Good Programming Practice 6.5 Place only expressions involving the control variables in the initialization and increment sections of a for statement. Manipulations of other variables should appear either before the loop (if they execute only once, like initialization statements) or in the body of the loop (if they execute once per iteration of the loop, like increment or decrement statements).

27  2006 Pearson Education, Inc. All rights reserved. 27 Outline Interest.cs (1 of 2)

28  2006 Pearson Education, Inc. All rights reserved. 28 Outline Interest.cs (2 of 2)

29  2006 Pearson Education, Inc. All rights reserved. 29 Good Programming Practice 6.6 Do not use variables of type double (or float ) to perform precise monetary calculations; use type decimal instead. The imprecision of floating-point numbers can cause errors that will result in incorrect monetary values.

30  2006 Pearson Education, Inc. All rights reserved. 30 Performance Tip 6.2 In loops, avoid calculations for which the result never changes—such calculations should typically be placed before the loop. [Note: Optimizing compilers will typically place such calculations outside loops in the compiled code.]

31  2006 Pearson Education, Inc. All rights reserved. 31 Outline DoWhileTest.cs

32  2006 Pearson Education, Inc. All rights reserved. 32 Fig. 6.8 | do while repetition statement UML activity diagram.

33  2006 Pearson Education, Inc. All rights reserved. 33 Error-Prevention Tip 6.4 Always include braces in a do...while statement, even if they are not necessary. This helps eliminate ambiguity between while statements and do...while statements containing only one statement.

34  2006 Pearson Education, Inc. All rights reserved. 34 Outline GradeBook.cs (1 of 5)

35  2006 Pearson Education, Inc. All rights reserved. 35 Outline GradeBook.cs (2 of 5)

36  2006 Pearson Education, Inc. All rights reserved. 36 Outline GradeBook.cs (3 of 5)

37  2006 Pearson Education, Inc. All rights reserved. 37 Outline GradeBook.cs (4 of 5)

38  2006 Pearson Education, Inc. All rights reserved. 38 Outline GradeBook.cs (5 of 5)

39  2006 Pearson Education, Inc. All rights reserved. 39 Common Programming Error 6.7 Forgetting a break statement when one is needed in a switch is a syntax error.

40  2006 Pearson Education, Inc. All rights reserved. 40 Outline GradeBookTest.cs (1 of 2)

41  2006 Pearson Education, Inc. All rights reserved. 41 Outline GradeBookTest.cs (2 of 2)

42  2006 Pearson Education, Inc. All rights reserved. 42 Software Engineering Observation 6.2 Provide a default label in switch statements. Cases not explicitly tested in a switch that lacks a default label are ignored. Including a default label focuses you on the need to process exceptional conditions.

43  2006 Pearson Education, Inc. All rights reserved. 43 Good Programming Practice 6.7 Although each case and the default label in a switch can occur in any order, place the default label last for clarity.

44  2006 Pearson Education, Inc. All rights reserved. 44 Fig. 6.11 | switch multiple-selection statement UML activity diagram with break statements.

45  2006 Pearson Education, Inc. All rights reserved. 45 Outline BreakTest.cs

46  2006 Pearson Education, Inc. All rights reserved. 46 Outline ContinueTest.cs

47  2006 Pearson Education, Inc. All rights reserved. 47 Software Engineering Observation 6.3 Some programmers feel that break and continue statements violate structured programming. Since the same effects are achievable with structured programming techniques, these programmers prefer not to use break or continue statements.

48  2006 Pearson Education, Inc. All rights reserved. 48 Software Engineering Observation 6.4 There is a tension between achieving quality software engineering and achieving the best- performing software. Often, one of these goals is achieved at the expense of the other. For all but the most performance-intensive situations, apply the following rule of thumb: First, make your code simple and correct; then make it fast and small, but only if necessary.

49  2006 Pearson Education, Inc. All rights reserved. 49 Fig. 6.14 | && (conditional AND) operator truth table.

50  2006 Pearson Education, Inc. All rights reserved. 50 Common Programming Error 6.8 In expressions using operator &&, a condition—which we refer to as the dependent condition—may require another condition to be true for the evaluation of the dependent condition to be meaningful. In this case, the dependent condition should be placed after the other condition, or an error might occur. For example, in the expression ( i != 0 ) && ( 10 / i == 2 ), the second condition must appear after the first condition, or a divide-by-zero error might occur.

51  2006 Pearson Education, Inc. All rights reserved. 51 Fig. 6.15 | || (conditional OR) operator truth table.

52  2006 Pearson Education, Inc. All rights reserved. 52 Error-Prevention Tip 6.5 For clarity, avoid expressions with side effects in conditions. The side effects may look clever, but they can make it harder to understand code and can lead to subtle logic errors.

53  2006 Pearson Education, Inc. All rights reserved. 53 Fig. 6.16 | ^ (boolean logical exclusive OR) operator truth table.

54  2006 Pearson Education, Inc. All rights reserved. 54 Fig. 6.17 | ! (logical negation) operator truth table.

55  2006 Pearson Education, Inc. All rights reserved. 55 Outline LogicalOperators.cs (1 of 3)

56  2006 Pearson Education, Inc. All rights reserved. 56 Outline LogicalOperators.cs (2 of 3)

57  2006 Pearson Education, Inc. All rights reserved. 57 Outline LogicalOperators.cs (3 of 3)

58  2006 Pearson Education, Inc. All rights reserved. 58 Fig. 6.19 | Precedence/associativity of the operators discussed so far.

59  2006 Pearson Education, Inc. All rights reserved. 59 Fig. 6.20 | C#’s single-entry/single-exit sequence, selection and repetition statements.

60  2006 Pearson Education, Inc. All rights reserved. 60 Fig. 6.21 | Rules for forming structured applications.

61  2006 Pearson Education, Inc. All rights reserved. 61 Fig. 6.22 | Simplest activity diagram.

62  2006 Pearson Education, Inc. All rights reserved. 62 Fig. 6.23 | Repeatedly applying the stacking rule (Rule 2) of Fig. 6.21 to the simplest activity diagram.

63  2006 Pearson Education, Inc. All rights reserved. 63 Fig. 6.24 | Repeatedly applying the nesting rule (Rule 3) of Fig. 6.21 to the simplest activity diagram.

64  2006 Pearson Education, Inc. All rights reserved. 64 Fig. 6.25 | “Unstructured” activity diagram.

65  2006 Pearson Education, Inc. All rights reserved. 65 Software Engineering Observation 6.5 Software designers do not generally create state machine diagrams showing every possible state and state transition for all attributes—there are simply too many of them. State machine diagrams typically show only the most important or complex states and state transitions.

66  2006 Pearson Education, Inc. All rights reserved. 66 Fig. 6.26 | State machine diagram for some of the states of the ATM object.

67  2006 Pearson Education, Inc. All rights reserved. 67 Fig. 6.27 | Activity diagram for a BalanceInquiry transaction.

68  2006 Pearson Education, Inc. All rights reserved. 68 Fig. 6.28 | Activity diagram for a Withdrawal transaction.

69  2006 Pearson Education, Inc. All rights reserved. 69 Fig. 6.29 | Activity diagram for a Deposit transaction.


Download ppt " 2006 Pearson Education, Inc. All rights reserved. 1 6 6 Control Statements: Part 2."

Similar presentations


Ads by Google