1. Use Intention-Revealing Names
2. Avoid Disinformation
3. Make Meaningful Distinctions
4. Use Pronounceable Names
5. Use Searchable Names
6. Avoid Encodings
7. Avoid Mental Mapping
8. Class Names
9. Method Names
10. Don’t Be Cute
11. Pick One Word per Concept
12. Don’t Pun
13. Use Solution Domain Names
14. Use Problem Domain Names
15. Don’t Add Gratuitous Context
16. Resources

The first paradigm to be adopted (but not the first to be invented) was structured programming, which was discovered by Edsger Wybe Dijkstra in 1968. Dijkstra showed that the use of unrestrained jumps (goto statements) is harmful to program structure. As we’ll see in the chapters that follow, he replaced those jumps with the more familiar if/then/else and do/while/until constructs.

We can summarize the structured programming paradigm as follows:

Structured programming imposes discipline on direct transfer of control.

The problem that Dijkstra recognized, early on, was that programming is hard, and that programmers don’t do it very well.

Dijkstra’s solution was to apply the mathematical discipline of proof. His vision was the construction of a Euclidian hierarchy of postulates, theorems, corollaries, and lemmas.

Same as mathematicians do, programmers should use proven structures, and tie them together with code that they would then prove correct themselves.

During his investigation, Dijkstra discovered that certain uses of goto statements prevent modules from being decomposed recursively into smaller and smaller units, thereby preventing use of the divide-and-conquer approach necessary for reasonable proofs.

Other uses of goto, however, did not have this problem. Dijkstra realized that these “good” uses of goto corresponded to simple selection and iteration control structures such as if/then/else and do/while. Modules that used only those kinds of control structures could be recursively subdivided into provable units.

This discovery was remarkable: The very control structures that made a module provable were the same minimum set of control structures from which all programs can be built. Thus structured programming was born.

As computer languages evolved, the goto statement moved ever rearward, until it all but disappeared.

At the end, there was no formal proof, and the Euclidean hierarchy of theorems was never built.

Structured programming allows modules to be recursively decomposed into provable units, which in turn means that modules can be functionally decomposed.

By following these disciplines, programmers could break down large proposed systems into modules and components that could be further broken down into tiny provable functions.

Given there was no formal proof, scientific method was then considered.

Science is fundamentally different from mathematics, in that scientific theories and laws cannot be proven correct, but can demonstrated in several ways.

Science does not work by proving statements true, but rather by proving statements false.

• Clean Architecture: A Craftsman’s Guide to Software Structure and Design, by Robert C. Martin

1. Use Intention-Revealing Names
2. Avoid Disinformation
3. Make Meaningful Distinctions
4. Use Pronounceable Names
5. Use Searchable Names
6. Avoid Encodings
7. Avoid Mental Mapping
8. Class Names
9. Method Names
10. Don’t Be Cute
11. Pick One Word per Concept
12. Don’t Pun
13. Use Solution Domain Names
14. Use Problem Domain Names
15. Don’t Add Gratuitous Context
16. Resources

The second paradigm to be adopted was actually discovered two years earlier, in 1966, by Ole Johan Dahl and Kristen Nygaard. These two programmers noticed that the function call stack frame in the ALGOL language could be moved to a heap, thereby allowing local variables declared by a function to exist long after the function returned. The function became a constructor for a class, the local variables became instance variables, and the nested functions became methods. This led inevitably to the discovery of polymorphism through the disciplined use of function pointers.

We can summarize the object-oriented programming paradigm as follows:

Object-oriented programming imposes discipline on indirect transfer of control.

• Clean Architecture: A Craftsman’s Guide to Software Structure and Design, by Robert C. Martin

1. Use Intention-Revealing Names
2. Avoid Disinformation
3. Make Meaningful Distinctions
4. Use Pronounceable Names
5. Use Searchable Names
6. Avoid Encodings
7. Avoid Mental Mapping
8. Class Names
9. Method Names
10. Don’t Be Cute
11. Pick One Word per Concept
12. Don’t Pun
13. Use Solution Domain Names
14. Use Problem Domain Names
15. Don’t Add Gratuitous Context
16. Resources

The third paradigm, which has only recently begun to be adopted, was the first to be invented. Indeed, its invention predates computer programming itself. Functional programming is the direct result of the work of Alonzo Church, who in 1936 invented l-calculus while pursuing the same mathematical problem that was motivating Alan Turing at the same time. His l-calculus is the foundation of the LISP language, invented in 1958 by John McCarthy. A foundational notion of l-calculus is immutability—that is, the notion that the values of symbols do not change. This effectively means that a functional language has no assignment statement. Most functional languages do, in fact, have some means to alter the value of a variable, but only under very strict discipline.

We can summarize the functional programming paradigm as follows:

Functional programming imposes discipline upon assignment.

• Clean Architecture: A Craftsman’s Guide to Software Structure and Design, by Robert C. Martin