In my previous post, The Elements of Programming Style: still worth reading , I argued that the book is still worth reading. Going back through the rules made me think about which ones I would give to a developer today. Most need no help. Clear names, small modules, testing boundary values and measuring before optimising are as useful now as they were when Brian Kernighan and P. J. Plauger wrote the book. A few rules, though, speak in the syntax of Fortran and PL/I. Fortran is still used in scientific and high-performance computing, but many developers won’t recognise an arithmetic IF or a DATA statement. In those cases, I’ve kept the original rule and written a version that carries its advice into other languages. These are the 72 rules I took from my reading notes, in order. Where I’ve changed one, I’ve included the original, the updated rule and my reason. 1. Write clearly - Don’t be too clever 2. Say what you mean, simply and directly. 3. Use library functions. 4. Use temporary var...
This book is unlikely to be of interest, unless you’re interested in data processing programs written in COBOL. However, I was interested in optimisation and the origin of: 1. Don’t do it. 2. Don’t do it yet. So I was satisfied with that at least. There are ideas here which have survived rather better than the examples, such as keeping programs simple, avoiding GO TO where possible and making each component responsible for validating the data it passes on. But much of the book is firmly rooted in the sort of data processing systems it was written for, and I struggled to relate many of the design techniques, particularly program inversion, to the way I think about software today. I did enjoy the occasional bit of personality, especially “A Moral Tale” and warnings to “resist this satanic temptation”. The exception was the chapter on optimisation, which was by far the most interesting part of the book. Jackson’s two rules are wonderfully simple: “Don’t do it” and “Don’t do it...