The first is the sequence construct, in which each task follows the previous one without altering the order of the tasks. Each task is executed once. Notice that primes (Figure 1.3) is based on this construct. The second is the decision construct, which allows only one of two tasks to be carried out, depending on a controlling logical condition. The appropriate task is executed once. It is the true task when the condition is true and the false task when the condition is false. The final construct is the loop, which enables a task to be repeated until a controlling condition no longer holds. Obviously, the loop must at some point end so that the next task can be executed. Failure to change the value of the controlling condition in order to end the loop task results in the infamous "infinite loop." Examples of algorithms formulated according to the three basic constructs appear in Figure 1.4 as structured flowcharts, along with their structured English equivalents. The corresponding versions are obvious.
Each construct has exactly one entry and one exit point. The constructs may be combined only by making the exit arrow of one the entrance arrow of another. This results in complex constructs that are sequences of constructs. The only allowed modification of a construct is the replacement of any of its tasks by one of the three basic constructs. This amounts to incorporating the task's refinements into the construct, producing a more complex construct.
There are two different ways to express a solution using these constructs and rules for their combination. One is to start with a basic construct and repeatedly apply modifications to it. Each modification corresponds to the use of a program segment for its implementation. This results in a final unmodularized flowchart, English equivalent, or program. See the unmodularized version of primes for an example. The second is to start with a basic construct, and, instead of modifying it, express the solution for each of its tasks as a separate function. This amounts to functionally modularizing each task's refinement, with the complete solution consisting of the collection of individual solutions. This results in a final collection of functionally modularized flowcharts, their English equivalents, or program components. Usually a combination of the two is better than using one method only. It is wise to keep each part of a solution to a reasonable size, say one page. This can serve as a guide to whether or not functional modularization (the use of a function) or modification (the use of a program segment) is appropriate. But remember: the primary goal is clarity.
Figure 1.4 The Basic Control Constructs and Their English Equivalents