Structured Programming | Research & Encyclopedia Articles

Structured Programming

Computers always execute programs in a fixed, sequential order only, with no intelligent choice or discretion. Most algorithms, however, require the application of certain procedures or execution of certain blocks of code repeatedly--for instance, the sorting of an array usually involves recursive application of the sort procedure a number of times. When an algorithm which asks for such repetition is translated into a program that is executed in sequential order, the tendency of computers to execute in strict sequential order must be altered on purpose--this is done by specifying "branches" or other instructions.

Branches are of two kinds, conditional or unconditional. A conditional branch has the form, "Check for this condition to be true; if it is, then do the following." A conditional branch thus causes execution to jump to a specific block of code if a certain condition is fulfilled. In commonly used programming languages, such branches are specified by the use of if and while statements in the program. The program evaluates a controlling expression, and carries out a certain execution if it is true, or while it is true, as the case may be. After the branch has been completed, the control of the program execution is returned either to the point where it started, or else to another predetermined point in the program.

Unconditional branches transfer execution to another point in the code, without providing a means by which it can be returned to the starting point. Most programming languages have a "goto" statement that fulfills this purpose. The syntax of this statement usually is of the form:

• goto Label

The Label is one that is given to a labeled statement, and the effect of the above is to unilaterally transfer control to that statement. Since no conditions are evaluated before such transfer, this is an unconditional branch. Control does not return to the point of origin unless some special provision is made; execution simply continues with the statements following the labeled statement to which control has been transferred.

Older programming languages such as FORTRAN and COBOL were used in the 1950s and later to produce code that used unconditional branching liberally. Such programs were found to be very difficult to read, debug, and maintain, and such use of unconditional branching earned a very bad name, and is now referred to as "spaghetti code." Beginning computer programming classes no longer teach use of goto statements as an essential feature, and programming language theory classes actively discourage its use, though the statement often survives in some form even in modern languages such as Java.

Along with the problems of spaghetti code, programming languages borrowed too many of each others' features and became increasingly involved and hard to produce workable code in. In order to solve these problems, Edsger W. Dijkstra, Tony Hoare, and other leading computer scientists of the late 1960s embarked on an effort to bring discipline to programming, by means of a technique they called structured programming. This technique rested on three important principles that they showed to be true:

• Only three control structures--sequence, selection, and repetition, are necessary for writing of programs.
• Unconditional branching is not necessary for any program.
• Programs written using just the three essential structures are easier to read, write, debug, and maintain compared to those that also use unconditional branching.

Structured programming therefore is the practice of creating programs using only the three essential structures, while eschewing the use of unconditional branches completely. A computer program that has been produced in accordance with the principles of structured programming is a structured program--such a program has a simpler design, is less complex, is more readable, and is easier to maintain. The structured programming paradigm also enforces a discipline on programming in general, and thus makes it easier for programmers to cooperate and to understand one another's code.