Safer C. Developing Software for High-integrity and Safety-critical Systems
Safer C: Developing software for high-integrity and safety-critical systems. Les Hatton. // McGraw-Hill Book Company, 1995. ISBN 007707640-0, 229 pages.
The book, despite being ~30 years old and talking about the first ISO C standard, is a goldmine when it comes to more timeless topics of quality and using programming languages.
A few quotes:
This book will argue forcibly that there is a property of software which experienced programmers can identify with quality without knowing the function of the software <…> There are many analogies in conventional engineering and manufacturing. An electrical engineer can look at a circuit board and decide on the basis of layout and quality of wire-wrap or soldering as to whether the product is well constructed, without knowing what the board does <…> A carpenter can look at a piece of furniture to see if it is constructed well or poorly. A builder can decide whether the overall layout of the drainage system of a house is sensible. <…> If they are really good products, they will suit their intended function equally well, but the point is that if they do not have intrinsic quality, they are intrinsically poor.
Unfortunately, it is only recently that some such measures have become obvious for software, and it is one of the prime objectives of this book to define them and demonstrate their reasonableness. This book wholeheartedly endorses this view and adds the following: Poor internal consistency and dependence on weak linguistic features implies poor external quality.
The property of good intrinsic product quality is here defined to comprise the following features:
Zero statically-detectable faults. These concern inconsistencies which are determinable without running a program, by simply inspecting its source code <…>
Zero transgressions of internal programming standards. This involves transgressions of an organization’s or project’s definition of good practice.
Zero dependence on relevant unspecified features or any undefined linguistic features. These refer specifically to parts of the language which are deemed questionable by the programming language standard definition itself.
Limitation of component complexity. This involves limiting the values of certain measurements of complexity to lie within prescribed bounds because of the known relationship between increased maintenance costs and the breaking of those bounds.
Even before the Agile Manifesto, decades before the clean code and TDD, people said basically the same things.
Another review of this book from 1995: https://onlinelibrary.wiley.com/doi/epdf/10.1002/stvr.4370050306