Structured programming
|
|
Structured programming can be seen as a subset or subdiscipline of procedural programming, one of the major programming paradigms. It is most famous for removing or reducing reliance on the GOTO statement (also known as "go to").
Historically, several different structuring techniques or methodologies have been developed for writing structured programs. The three most common are
- Jackson Structured Programming, which is based on aligning data structures with program structures,
- Dijkstra's structured programming, which is based on splitting programs into sub-sections, each with a single point of entry and of exit,
- and a view derived from Dijkstra's which also advocates splitting programs into sub-section with a single point of entry, but is strongly opposed to the concept of a single point of exit.
Most people mean one of the two latter when they use the term structured programming, and that is what this article will discuss.
It may be helpful to begin this discussion by briefly citing Dijkstra's objectives, as expressed in his seminal article, Notes on Structured Programming:
- "When we now take the position that it is not only the programmer's task to produce a correct program but also to demonstrate its correctness in a convincing manner, then the above remarks have a profound influence on the programmer's activity: the object he has to produce must be usefully structured."
- "... In what follows it will become apparent that program correctness is not my only concern, program adaptability or manageability will be another. ..." 1
It is possible to do structured programming in almost any procedural programming language, but since about 1970 when structured programming began to gain popularity as a technique, most new procedural programming languages have included features to encourage structured programming, (and sometimes have left out features that would make unstructured programming easy). Some of the better known structured programming languages are Pascal and Ada.
At the level of relatively small pieces of code, structured programming typically recommends simple, hierarchical program flow structures. These can be obtained in most modern languages by using only structured looping constructs, often named "while", "repeat", "for". Often it is recommended that each loop should only have one entry point (and in the original structural programming, also only one exit point), and a few languages enforce this.
Alternative thinking on structured loops exists. Donald Knuth has advocated flow graphs that can be written with all forward branches drawn to the left of the code, all backward branches drawn to the right, and no branches crossing each other in this representation. Many of those knowledgeable in compilers and graph theory have advocated allowing only reducible flow graphs.
Coders should break larger pieces of code into shorter subroutines (functions and procedures in some languages) that are small enough to be understood easily. In general, programs should use global variables sparingly; instead, subroutines should use local variables and take arguments by either value or reference. These techniques help to make isolated small pieces of code easier to understand without having to understand the whole program at once.
Structured programming is often (but not always) associated with a "top-down" approach to design. In this way designers map out the large scale structure of a program in terms of smaller operations, implement and test the smaller operations, and then tie them together into a whole program.
By the end of the 20th century, the majority of programmers endorsed structured procedural programming. Some claim that colleagues can understand a structured program more easily, leading to improved reliability and easier maintenance. Attempts to actually measure this have been rare, and there is a suspicion in some circles that the benefits are real but small.
Towards the end of the 20th century, designers have created new paradigms loosely based on procedural programming that accept the lessons of structured programming but attempt to go beyond this in providing structure for data as well as for program flow. Object-oriented programming in most cases can be seen as an example of this, although there are also some object-oriented variants that are not procedural. Some critics of object-oriented techniques feel that they return to navigational database-like techniques, which are a kind of "data GOTO" of their own.
Unstructured languages define control flow largely in terms of a GOTO command that transfers execution to a label in code. Structured programming languages provide constructs (often called "if-then-else", "switch", "unless", "while", "until", and "for") for creating a variety of loops and conditional branches of execution, although they may also provide a GOTO to reduce excessive nesting of cascades of "if" structures, especially for handling exceptional conditions.
Multiple points of exit
The original structural programming advocated dividing programs into subsections that have single point of entry, and single point of exit. While usually there aren't many reasons to have multiple points of entry, very few programs naturally follow the single point of exit paradigm.
A typical example of a simple procedure would be reading data from a file and processing it:
open file;
while (reading not finished)
{
read some data;
if(error){
stop the subprogram, inform rest of the program about the error;
}
}
process read data;
finish the subprogram;
The "stop and inform" may be achieved by throwing an exception, second return from the procedure, labelled loop break, or even a goto. As the procedure has 2 exit points, it breaks the rules of Dijkstra's structured programming. Coding it in accordance with single point of exit rule would be very cumbersome. If there were more possible error conditions, with different cleanup rules, single exit point procedure would be extremely hard to read and understand, very likely even more so than an unstructured one with control handled by goto statements. On the other hand, structural programming without such a rule would result in very clean and readable code.
Most languages have adapted the multiple points of exit form of structural programming. C allows multiple paths to a structure's exit (such as "continue", "break", and "return"), newer languages have also "labelled breaks" (similar to the former, but allowing breaking out of more than just the innermost loop) and exceptions.
While using those abilities may bring both advantages and disadvantages to the readability, providing them is clearly advantageous, as the programmer may use them when they're fit and simply not use them when a single point of exit structure would be more appropriate.
See also
- Unstructured programming (contrast)
- Programming paradigms
- Control flow (more detail of high-level control structures)
References
- Edsger Dijkstra, Notes on Structured Programming (http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF), pg. 6
ja:構造化プログラミング lt:Struktūrinis programavimas ms:Pengaturcaraan Berstruktur nl:gestructureerd programmeren pl:Programowanie strukturalne