Structured programming

Structured programming is a programming paradigm aimed at improving the clarity, quality and development time of a computer program using only subroutines and three basic control structures: sequence, selection (if and switch) and iteration (for and while loops); likewise, the use of unconditional transfer (GOTO) is considered unnecessary and counterproductive; this instruction usually ends up generating the so-called spaghetti code, which is much more difficult to follow and maintain, as well as causing numerous programming errors.

It arose in the 1960s, particularly from the work of Böhm and Jacopini, and a famous writing from 1968: "The goto sentence, considered harmful", by Edsger Dijkstra. Its postulates would be reinforced, at a theoretical level, by the structured program theorem and, on a practical level, by the appearance of languages like ALGOL, endowed with consistent and well-formed control structures.

Elements

Control Structures

Following the structured program theorem, all programs are seen as composed of control structures:

• Sequence: ordered statements or subroutines executed in sequence.
• Selection: one or more instructions are executed depending on the status of the program. This is usually expressed with the keyword as if..then..else..endif. The conditional statement must have at least one true condition and each condition must have a maximum point of departure.
• Iteration: an instruction or block is executed until the program reaches a certain state, or operations have been applied to each element of a collection. This is usually expressed with keywords like while, repeat, for or do.until. Often, it is recommended that each loop only have an entry point (and in the original structural programming, also only a starting point, and some languages impose it).
• Recursion: a statement is executed repeatedly calling itself until the termination conditions are met. While in practice they are similar to iterative loops, recursive loops can be more computer-efficient and implemented differently as a cascade stack.

Graphical representation of the three basic patterns (sequence, selection and repetition) using NS (blue) diagrams and flow charts (green).

Subroutines

Subroutines are units that can be called, such as procedures, functions, methods, or subprograms. They are used to allow a single statement to reference a sequence.

Blocks

Blocks are used to allow groups of statements to be treated as if they were a single statement. The "block structured" they have a syntax for enclosing structures in some formal way, like an if statement in parentheses. if..fi as in ALGOL 68, or a section of code enclosed in BEGIN..END brackets, as in PL/I and Pascal, whitespace indentation as in Python, or the {...} braces of C and many later languages.

Origins of Structured Programming

At the end of the 1970s, a new way of programming arose that not only allowed the development of reliable and efficient programs, but also these were written in a way that facilitated their understanding in subsequent improvement phases.

The structured program theorem, proposed by Böhm-Jacopini, shows that any program can be written using only the following three control instructions:

• Sequence.
• Conditional instruction.
• Iteration (bucle of instructions) with initial condition.

Only with these three structures can all possible programs and applications be written. Although programming languages have a greater repertoire of control structures, these can be built using the three basic ones mentioned.

History

Theoretical foundation

The structured program theorem provides the theoretical basis for structured programming. He points out that the combination of the three basic structures, sequence, selection and iteration, are sufficient to express any computable function. This observation did not originate with the structured programming movement. These structures are enough to describe the instruction cycle of a central processing unit, as well as the operation of a Turing machine. Thus, a processor is always executing a "structured program" in this sense, even if the instructions it reads from memory are not part of a structured program. However, authors usually credit the result to a paper written in 1966 by Böhm and Jacopini, possibly because Dijkstra had quoted this writing. The Structured Program Theorem does not answer how to write and analyze a structured program in a useful way. These themes were addressed during the 1960s and early 1970s, with important contributions from Dijkstra, Robert W. Floyd, Tony Hoarey, and David Gries.

Discussion

P. J. Plauger, an early adopter of structured programming, described his reaction to the structured program theorem:

We converts wave this interesting bit of news under the noses of die-hard assembly language programmers who kept trotting along twisted bits of logic and saying, 'I bet you can't structure this.' Neither the proof by Böhm and Jacopini, nor our repeated successes in writing structured code, got them a day sooner than they were ready to be convinced.

Donald Knuth accepted the principle that programs should adapt assertively, but disagreed (and still disagrees)^{[citation needed]} with the deletion of the GOTO statement. In his 1974 paper "Structured Programming with Goto Statements", he gave examples where he believed that a direct jump leads to clearer and more efficient code without sacrificing demonstrability. Knuth proposed a looser structural constraint: It must be possible to set up a program flowchart with all forward branches on the left, all backward branches on the right, and no intersecting branches. Many of the graph theorists and compilers have advocated allowing only reducible stream graphs^{[who?][when?]}.

Structured programming theorists gained an important ally in the 1970s after IBM researcher Harlan Mills applied his interpretation of structured programming theory to the development of an indexing system for the data file. investigation by the New York Times. The project was a great engineering success, and was cited by managers at other companies in support of adopting structured programming, although Dijkstra criticized the ways in which Mills's interpretation differed from published work.

It wouldn't take until 1987 for the question of structured programming to come to the attention of a computer science journal. Frank Rubin did so in that year, writing: "Is 'GOTO statement considered harmful' considered harmful?" This was followed by numerous objections, such as a response from Dijkstra himself harshly criticizing Rubin and the concessions other authors made when responding to him.

Result

By the late 20th century, almost all scientists are convinced that it is useful to learn and apply programming concepts structured. High-level programming languages that originally lacked programming structures, such as FORTRAN, COBOL, and BASIC, now have them.

Advantages of structured programming

Among the advantages of structured programming over the previous model (today derogatorily called spaghetti code), it is worth mentioning the following:

• Programs are easier to understand, they can be read sequentially and there is no need to track line jumps (GOTO) within code blocks to try to understand internal logic.
• The program structure is clear, since the instructions are more linked or related to each other.
• The effort is optimized in the test and depuration phases. Follow-up to programme failures or errors (debugging), and with it its detection and correction, it is greatly facilitated.
• Maintenance costs are reduced. Similarly to depuration, during the maintenance phase, modification or extension of the programs is easier.
• The programs are easier and faster to build.
• The performance of programmers is increased.

Structured Programming Languages

Although it is possible to develop structured programming in any programming language, a procedural programming language is more suitable. Some of the languages used initially for structured programming include ALGOL, Pascal, PL/I, and Ada, but most new procedural programming languages since then have included features to encourage structured programming and sometimes deliberately omit features in a effort to make unstructured programming more difficult.

New paradigms

After structured programming, new paradigms have been created such as modular programming, object-oriented programming, layered programming and others, as well as new programming environments that facilitate the programming of large applications and systems.