Structured Programming and Unstructured Artifacts

Most common programming languages consist of three essential sub-languages. (There may be other sub-languages such as a macro facility and I/O formatting.) Each of these sub-languages have structures for building useful programs out of atoms of data and computation, and each sub-language also contains an unstructured artifact that lets you escape the constraints of structures. When you use an unstructured artifact, you gain freedom to go wild in your code, but you inevitably make your code less comprehensible and more defect-prone. You might think that use of unstructured artifacts would be discouraged, but in fact attitudes have been uneven.

Structured and Unstructured

Here is a summary of the three sub-languages with their structuring mechanisms and unstructured artifacts.

Structuring Principle	Sub-Language
	Algorithm Structure	Data Structure	Expression
Structures within a Module
Sequence	Block of statements one after the other	Record or Struct	Ordinary formula, e.g., 2 * X + 1
Alternation	‘If’ / ‘Case’ statement	Variant-record or Union	Conditional formula, e.g., A>B ? A : B
Repetition	‘For’ / ‘While’ / ‘Until’ statement	Array or List	–
Structures to link Modules
Definition	Subroutine	Object	Function
Invocation	Call to the subroutine	Use of the reference to the object	Call to the function from within a formula
Unstructured Artifact
Artifact	‘Go to’ statement	Pointer	Flag variable

We figured out quite a long time ago that unstructured artifacts only bring grief to people (including yourself at a future time) who must read and modify your code, and that you can just about always replace unstructured artifacts in your code with structures that deliver the same results.

Programming using structured techniques is like driving using rules of the road. Sure, in some given situation you could get ahead by driving however you want. Widespread driving without rules, however, causes everyone to always arrive later at their destinations and more frustrated. To put it another way: to make use of an unstructured artifact is a way to avoid thinking through your code when you’re designing it, but at a cost of future efforts to read and understand code that is, in essence, an un-thought-out tangle.

The Pointer and the Go-To

But unstructured artifacts do not all have the same reputation. While the ‘go to’ statement was vilified as far back as the late 1960s, the pointer remained in programmers’ good graces for more than twenty years after. In 1968, Edsger W. Dijkstra published his famous letter “Go To Statement Considered Harmful” (original here^{[payment required]}, copy here), and within ten years programmers had thoroughly spurned the use of ‘go to’ statements. In contrast, pointer variables for a long time were quite respectable; indeed, C programmers have long been taught how to make routine use of pointers in their code. Most C programming novices struggled to comprehend C’s pointers and pointer arithmetic, yet this was seen not as an indictment of the pointer but as a sign that C programming is just inherently tricky.

We are improving. ‘Go to’ statements were eliminated through deliberate changes to programming practices and how programming was taught. Pointer variables have been disappearing as a side effect of programmers adopting programming languages built on principles of object orientation.