Paul Grenyer

As I continue working on projects of my own, as well as those in my day job, I am learning more about the best ways to use AI to create software. Mostly Claude and sometimes Codex. One thing I cannot help noticing is the sheer number of comments AI adds to the code. In January 2025, I wrote a blog post called Comments in Code: Just Don’t Do It , in which I quoted Uncle Bob: It is well known that I prefer code that has few comments. I code by the principle that good code does not require many comments. Indeed, I have often suggested that every comment represents a failure to make the code self explanatory. I have advised programmers to consider comments as a last resort. I went on to say: Comments should always be “why”, never “what”, and only when     absolutely necessary. If you feel the need to write a “what” comment, put the code in     a well-named, meaning descriptive, function instead. I stand by this view. Comments should be few and far between and,...

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...

The Foundation series has been my go to for a good, enjoyable read over the last two years, so naturally I moved on to Asimov’s Robot series afterwards. However, the short stories in I, Robot were mostly a disappointment. They feel self indulgent, with too much philosophy and science, Asimov showing off, and not enough story. The most enjoyable moments come from the stories featuring Gregory Powell and Mike Donovan. Their banter and the relationship between them provide some much needed amusement and were easily the highlight of the book for me. However, it did give me food for thought for the current potential issues with the rapid development of AI at the moment, and the many concerns around safety. I wonder if all we need is: An AI may not injure a human being or, through inaction, allow a human being to come to harm. An AI must obey the orders given it by human beings except where such orders would conflict with the First Law. An AI must protect its own existence as long as such p...

The Elements of Programming Style by Brian W. Kernighan and P. J. Plauger is one of those books that makes some excellent points that every software engineer should know and bear in mind every day. The central message is simple: write clearly and don’t be too clever. Say what you mean, use the language’s good features, choose names that won’t be confused, and structure your code so that its intent is obvious. There is plenty here that still feels completely relevant, including modularisation, encapsulation, keeping modules focused on one thing, making coupling visible, defensive programming and, perhaps most importantly, not stopping with your first draft. The advice to revise and refactor rather than being satisfied with code that merely works is something that could be written today. The chapters on efficiency and documentation particularly stood out to me. The authors make the point that if a program doesn’t work, it doesn’t matter how fast it runs, and that you should make it right...

Not Like That! How to build the wrong thing on purpose instead of the right thing by accident by Adam L. Coombes I really like this book. It’s divided into seven-minute chapters, which I found particularly effective. They’re short enough that you can get through one whenever you have a few minutes, but there’s enough in each one to give you something to think about. The writing is engaging and amusing too, which makes what could otherwise be quite a dry subject surprisingly easy to read. At first, I thought the author had misunderstood Agile. The early chapters seemed to be making the argument that Agile had somehow become a rigid process, and that we had forgotten the importance of actually talking to the people who use the software. My immediate reaction was: wasn’t this what Agile was supposed to solve 25 years ago? There’s a chapter called Agile Just Made It Faster , and initially I thought this was where we were going to disagree. But I think I was wrong. The author isn’t really a...