ArticleslgStudy

engineering

Structured programming

Structured programming is a engineering topic covered in the lgStudy science library. This page brings together a partial reference excerpt, illustrations, worked examples, real-world applications and a short study plan, so you can understand Structured programming rather than just read about it. In short: Structured programming is a programming paradigm characterized by source code that uses block-based source code structure to encode control flow such as sequence, selection (i.e. if-then-else and switch) and iteration (i.e. for and while). Originally, the central goal of the structured programming movement was to eliminate the need for and use of the goto statement.

Structured programming — main illustration
Structured programming — illustration

Key takeaways

  • Structured programming belongs to engineering; place it in that map before memorising details.
  • Learn the definition first, then one example that makes the definition concrete.
  • Connect Structured programming to a quantity you can measure, compute or draw — that is where exam questions come from.
  • Reproduce the core statement of Structured programming from memory before moving on to harder problems.

Reference excerpt

Structured programming is a programming paradigm characterized by source code that uses block-based source code structure to encode control flow such as sequence, selection (i.e. if-then-else and switch) and iteration (i.e. for and while). Originally, the central goal of the structured programming movement was to eliminate the need for and use of the goto statement. As goto provides powerful and flexible flow control, it can be used to write any arbitrarily complex algorithm, but the resulting code often has significant quality issues, commonly described as spaghetti code. Structured programming replaces goto with constructs that tend to result in better code. The paradigm became popular and for the most part achieved the goal of supplanting goto. In fact, its ubiquity is so thorough that for much of software development, it is simply the way code is written, no longer a topic of discussion as it once was. Structured programming is sometimes associated with modular programming even though they are different. In a general sense, structured implies a sense of modularity and of being written to be efficient and easy to understand and modify, but this is not what structured programming means in a narrow sense. After structured programming became popular, the style of programming that preceded it was retroactively called non-structured programming. Although technically a programming paradigm, it differs from other paradigms in that it was not intentionally designed. It was simply the state-of-the-art before structured programming was envisioned.

History The paradigm emerged in the late 1950s with the appearance of the ALGOL 58 and ALGOL 60 programming languages, with the latter including support for block structures. Contributing factors to its popularity and widespread acceptance, at first in academia and later among practitioners, include the publication of what is now known as the structured program theorem in 1966, and the publication of the influential "Go To Statement Considered Harmful" open letter in 1968 by Dutch computer scientist Edsger W. Dijkstra, who coined the term structured programming.

Theoretical foundation The structured program theorem provides the theoretical basis of structured programming. It states that three ways of combining programs—sequencing, selection, and iteration—are sufficient to express any computable function. This observation did not originate with the structured programming movement; these structures are sufficient to describe the instruction cycle of a central processing unit, as well as the operation of a Turing machine. Therefore, 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 1966 paper by Böhm and Jacopini, possibly because Dijkstra cited this paper himself. The structured program theorem does not address how to write and analyze a usefully structured program. These issues were addressed during the late 1960s and early 1970s, with major contributions by Dijkstra, Robert W. Floyd, Tony Hoare, Ole-Johan Dahl, and David Gries.

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

Us converts waved this interesting bit of news under the noses of the unreconstructed assembly-language programmers who kept trotting forth twisty bits of logic and saying, 'I betcha can't structure this.' Neither the proof by Böhm and Jacopini nor our repeated successes at writing structured code brought them around one day sooner than they were ready to convince themselves. Donald Knuth accepted the principle that programs must be written with provability in mind, but he disagreed with abolishing the GOTO statement, and as of 2018 has continued to use it in his programs. 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 provability. Knuth proposed a looser structural constraint: It should be possible to draw a program's flow chart with all forward branches on the left, all backward branches on the right, and no branches crossing each other. Some of those knowledgeable in compilers and graph theory have advocated allowing only reducible flow graphs. Structured programming theorists gained a major 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 New York Times research file. The project was a great engineering success, and managers at other companies cited it in support of adopting structured programming, although Dijkstra criticized the ways that Mills's interpretation differed from the published work. As late as 1987, it was still possible to raise the question of structured programming in a computer science journal. Frank Rubin did so in that year with an open letter titled "'GOTO Considered Harmful' Considered Harmful". Multiple objections followed, including a response from Dijkstra that sharply criticized both Rubin and the concessions other writers made when responding to him.

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

Control structures Following the structured program theorem, a program is composed of three control structures:

… excerpt ends here. Continue reading the full article.

Worked examples

Example 1 — a first encounter with Structured programming

Start with the simplest possible case. Write down what Structured programming claims or describes in one sentence, then invent the smallest concrete situation in which that sentence is true. In engineering, the smallest case is usually a single object, a single equation or a single measurement. Check that every symbol or term in your sentence has a meaning in that case.

Example 2 — changing one variable

Take the situation from Example 1 and change exactly one quantity: double it, halve it, or set it to zero. Predict what should happen to Structured programming before you calculate. Comparing your prediction with the result is the fastest way to find out whether you understand the idea or only the words.

Example 3 — an exam-style question

Typical questions about Structured programming ask you to (a) state it precisely, (b) apply it to given data, and (c) explain a limitation. Practise writing all three answers in under five minutes; the third part is what separates a full-mark answer from an average one.

Applications of Structured programming

In research
Structured programming appears in engineering research whenever the underlying quantities have to be modelled precisely. Papers usually cite it as a starting assumption and then explore where it breaks down.
In technology and industry
Engineering practice reuses Structured programming in design rules, simulations and safety margins. Knowing the idea lets you read a specification sheet and understand why the numbers look the way they do.
In the classroom
Structured programming is common in secondary-school and first-year university syllabi. It links to neighbouring topics Holism, Programming paradigms, so understanding it makes those chapters shorter.
In everyday life
Look for Structured programming outside the textbook — in sport, cooking, traffic, electronics or the sky above you. An example you found yourself is remembered far longer than one you were given.
Ask Teacher Smith questions about this articleOpens your AI tutor with a question about “Structured programming” →

Affiliate

Preply — study more efficiently by working with a personal tutor. 50% off.

How to study Structured programming in 20 minutes

  1. Read the reference excerpt below once, without taking notes.
  2. Close the page and write down what Structured programming means in your own words.
  3. Compare your version with the excerpt and mark what you missed.
  4. Work through the three examples above with pen and paper.
  5. Explain Structured programming out loud to somebody else — or to Teacher Smith in the lgStudy chat.

Frequently asked questions

What is Structured programming in simple terms?

Structured programming is a programming paradigm characterized by source code that uses block-based source code structure to encode control flow such as sequence, selection (i.e. if-then-else and switch) and iteration (i.e. for and while). Originally, the central goal of the structured programming…

Why does Structured programming matter?

Because it connects several engineering ideas at once: it gives you a definition you can apply, a quantity you can calculate, and a way to check whether a result is plausible.

How should I study Structured programming?

Read the excerpt, restate it from memory, then work through the examples and applications listed on this page. The five-step study plan above takes about twenty minutes.

What does this page cover?

It gives you a compact reference excerpt plus original lgStudy explanations, examples, applications and study material on Structured programming.

Tags

  • Holism
  • Programming paradigms

Keep exploring