Clean Architecture —Structured Programming
A chapter in which Uncle Bob tells us more about the structured programming paradigm.
About this article
This is a part of my series of articles where I go chapter-by-chapter through the “Clean Architecture” by Robert.C.Martin and share my thoughts, analysis and pieces of knowledge I’ve gathered. Previous part can be found here.
GOTO hell
In the early days of programming (around 1950/60s), use of unrestricted jumps (goto instructions) was as frivolous as it could get. And as anyone can imagine, jumping around in the memory all the time wasn’t very friendly for the readability of code.
Due to this, as projects grew bigger and bigger they became too complex for programmers to manage. A program of any complexity contains so many details, that the human brain cannot even hope to manage it well without some kind of external help. Even one small mistake can cause the execution of a program to fail miserably.
Programmers had a problem, a problem that few knew about. How could anyone keep on coding if there was no way for programmers to verify if their programs do actually work correctly? How can you verify something you have no control over or something that’s way too complex for your human brain to handle?
Dijkstra to the rescue
In 1968, a (or rather THE) Dutch programmer Edsger W.Dijkstra wrote a letter to the editor of CACM. The title of this letter was “Go To Statement Considered Harmful”.
For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all “higher level” programming languages.
In this letter Dijkstra shared his discovery that certain uses of goto statements are harmful to the structure of code as they prevent modules from being decomposed recursively into smaller and smaller units, and thus preventing use of divide-and-conquer approach. According to Dijkstra, small units and divide-and-conquer were necessary for creation of a mathematical proof of correctness for any algorithm.
However, not all uses of gotos were “bad”, the ones corresponding to simple selection (if/then/else) and iteration control structures (do/while) could be easily subdivided into small, provable units.
Dijkstra used enumeration to prove sequential statements and induction to prove iteration correct. Event though such proof were quite hard to find and very time consuming, they were the first formal method of proving that a program is completely correct. And so, with the removal of frivolous gotos and introduction of control instructions structured programming paradigm was born. After a heated debate the programming society has accepted that Dijkstra was right about the gotos.
When proof is a problem
In real life however, finding a formal mathematical proof for every piece of code was way too laborious. Programmers enjoyed this new way of proving that whatever they wrote did actually work, but deadlines are deadlines and projects cannot wait forever. And so, instead of mathematical proofs, tests were introduced.
It’s true that tests cannot show the total absence of bugs and errors, only the presence of them. That’s good enough for almost all real-life programs.
Structured programming forces us to decompose a program into a set of small testable functions, thanks to that we can test our programs and deem them to be correct enough for our purposes.
Summary
I encourage you to share your feedback and point of view with me, it’s the best way for all of us to learn and grow. Also, check out the complete book, it’s a really wonderful source of knowledge for any developer. My articles are just a shallow summary of information that can be found in this book, do yourself a favor and read it whole! Next part can be found here.
