Structured programming is a methodology that attempts to minimize the complexity associated with designing, writing, and modifying individual algorithms, so it is focused on the very detailed level of programming.
The fundamental idea of structured programming is simple: Only use control constructs that have one entry and one exit point. In C#, those structured constructs are represented by while, do-while, for, if-else, and switch.
The basic ideas associated with structured programming were conceived during the 1960s and 1970s. Before the advent of this important methodology, the goto statement had been applied to implement much of the logic in a program. However, it soon became apparent that many of the problems experienced by programmers were caused by the indiscriminate use of this jump statement, leading to what is often called spaghetti code (see Figure 9.9).
Fortunately, a better alternative was discovered in the form of the structured programming constructs for which it is true that the flow of control only has a single entry point and a single exit point. The while, do-while, for, if-else, and switch statements all belong to this category, as illustrated in Figure 9.10. Each of those constructs can be viewed as a black box from outside of their scope. From this viewpoint, the programmer can always be certain that the flow of control enters at the top in one entry point and exits at the bottom from one exit point. Consequently, when the construct is terminated, the next statement to follow is executed.
Recall how classes and objects used in object-oriented programming are used to break down the overall problem domain of a programming project into simpler, self-contained pieces. Each piece can be created, viewed, and modified separately. Well, this age-old strategy of breaking complex problems into simpler solvable parts is also at play in structured programming, but this time at the very detailed level of a program. Whereas the uncontrolled use of goto statements forces us to look at numerous aspects of an algorithm simultaneously, the structured constructs allow us to break an algorithm up into smaller self-contained pieces that, to a certain degree, can be viewed and analyzed separately, as they solve separate parts of a problem. Figure 9.11 illustrates this point.
Flowcharts can lead to an apparent need for goto statements.
Expressing the flow of control visually with a flowchart can be a great aid in understanding and communicating the inner logic of a specific algorithm. However, there is at least one drawback of designing algorithms with flowcharts. It is very easy to call for the use of goto statements in the resulting source code. This is so because an arrow in a flowchart represents transfer of control from one part of the program to another. It is tempting and easy to get carried away and draw arrows to all kinds of weird and wonderful places when drawing a flowchart. Many of these jumps can, unless utmost care is taken, only be accomplished in the resulting C# source code through the use of the goto statement and not any of the structured programming elements.
This is one of the reasons why many programmers prefer pseudocode to flowcharts. They force the programmer to think in terms of structured programming elements, because pseudocode is written as lines of text from start to finish; erratic jumps do not easily fit in with this format.
During the 1960s and 70s, computer scientists showed that any logic implemented by using goto statements could be implemented by a combination of the structured constructs discussed here. Because programmers then had no excuse for using goto statements in languages containing the structured constructs, the structured programming movement became synonymous with a crusade against the evil goto statement.
break, continue, and Structured Programming
The effects achieved by applying the break and continue statements inside iteration statements can be achieved by a combination of the basic structured constructs (while, do-while, for, if-else, and switch). Some programmers believe break and continue breach the intent of structured programming and never use them. Other programmers argue that break and continue, when correctly applied, produce faster programs. Often, the best route to follow in this situation is first to write the source as clearly and correctly as possible (minimizing the use of break and continue), disregarding the speed of execution. If needed, tuning can then be performed at a later stage.