The Elements of Programming Style by Brian W. Kernighan

The Elements of Programming Style Reviews

• 
  Patrick Tilsen

  This is almost a must-read for computer scientists, computer engineers, software engineers, and anyone who will code for a living. Almost. I was very tempted to give this book a four, but the content is too good and not replicated in aggregate in any other source of which I'm aware.
  
  The problem is that the FORTRAN and PL/I examples are going to be virtually unreadable by a modern programmer. Many of the examples and their lessons were still very clear, but others were almost impossible to parse. By the end, I probably learned enough FORTRAN in PL/I that I could go back and "decompile" most of the example programs. Additionally, many of the problems the authors describe at length were solved in C or C++, and more are absent in higher-level languages, and therefore inaccessible to newer students and more novice programmers. If someone were to write a "third edition" in C or C++ and swap some of the antiquated FORTRAN issues for modern C-and-C-like-language issues or even object-oriented issues, it could serve as a valuable, accessible guide for the current generation.
  
  Despite these issues, I am inclined to give the book five stars, given my limited choices on a five-point scale. It is incredibly valuable, and will likely be one of the few I use for reference in the years to follow.
• 
  G. Branden

  An old classic--clear, enjoyable, and full of good common sense, nearly all of which still applies (an example of what doesn't: "Avoid Fortran's arithmetic IF").
  
  I wavered between three and four stars for this title; the use of what are now antiquated programming languages (PL/I and Fortran IV) marred my enjoyment a little bit, only because I had to stop and gasp at infelicities of syntax or catch my breath at the absence of features which are now considered mandatory for any serious programming language.
  
  Still, that's a minor defect, and not in any way the fault of the authors, but of my perverse decision to read this title thirty years after its publication. Most of the advice is still sound, and you will still see most of it violated by your colleagues.
  
  Were I generation older and reading this a generation ago, I would likely have found this a five-star title. It's held up pretty well given its field.
  
  Those seeking an updated version of this title should consult Kernighan and Pike's
  The Practice of Programming.
  
• 
  Andrew Nguyen

  Brian Kernighan is the co-author of THE book on THE most important programming language and also an OG contributor to Unix. The dude is a freaking legend. I wanted to read this because I watched the interview where Brian Kernighan
  explains the origin of grep. During the interview, he just struck me as such a kind, smart dude that I wanted to get inside his brain a little bit.
  
  The book looks at several small code samples, improves them and explains the simple principle behind the improvement. The suggestions are clean, simple and always made the code noticeably more usable. Another thing I loved about this book was the tone. I read a lot of code for work, and it gets pretty easy to be unhelpfully snarky when code is written poorly. Kernighan provides thoughtful, actionable advice for how to make bad code better. The tone isn't angry at how bad people are at programming, but more understanding about how these mistakes can be made and avoided.
  
  My (and everyone's) one big gripe is how outdated the FORTRAN examples are. I don't know any FORTRAN, so some of the code examples weren't easy to follow unless I googled a lot of FORTRAN syntax. It was a little frustrating to get advice like, "Avoid GOTO statements" when most programmers don't even know what that language construct is nowadays. This book is dying for a re-boot. And if it ever does get re-written in a modern language, I'm gonna read the hell out of it.
• 
  Chris Sullins

  It was good, but pretty old. Limited. Some of the problems they point out have been solved by newer programming languages (like C; this is an *old* book). It's focused on small, self-contained programs, such as you would find in textbooks, and doesn't do much to extend their prescriptions to apply to larger programs.
• 
  Nikolay

  It's ridiculous that this book was written 35 years ago and programmers still struggle with simple common sense. The software industry constantly reminds how young it is.
  
  All the advice in the books is great and thoughtful.
  
  Why 4 stars? The examples are so outdated that the levels of abstractions changed and it looks like the authors are mixing them.
• 
  David

  It is worth noting that the examples are in Fortran IV and PL/I.
• 
  Spencer Williams

  Some of the advice is outdated now, but the motivations for those advice can still be applied to modern languages and techniques.
• 
  Jack

  First read it a few years ago, worth rereading on a regular basis for any programmer. The examples are, unfortunately, in a very ancient Fortran dialect and PL/I, and a few of their recommendations are specific to those languages, but much of it applies just as well today as it did in the 70s. The Strunk & White of programming.
• 
  Max Galkin

  Almost 40 years since this book was published and still so many of its great practices are being violated, hurting readability, clarity and correctness of code. I wish every computer programmer would read this book and follow its advice.
• 
  Jack Repenning

  A classic, in a well-populated genre. Humorous, insightful, memorable.
• 
  Alex

  This book will turn 50 soon. And some parts of it haven't aged that well. It uses Fortran (the one where arithmetic if was the norm, and logic if was the new thing) and PL/I. But that doesn't matter for the most part. What matters is the approach and the rules. The approach is to take a piece of code, analyse its failings, improve it, and derive a general rule. And for the most part the rules are still valid today. Let that sink in. The half life of technical books these day is a few years. This book's rules are mostly applicable after half a century. And that is remarkable in itself.
  
  There are other notable things about it though. If you've read any other book by Kernighan ("Software Tools" and its Pascal version, "The Practice of Programming") you'll recognise his later style in incipient form. It's a rare view into how a programmer's views evolve and mature. And much the same for Plauger, though I've only read "Programming on Purpose" from his later work.
  
  And for computing history or language geeks this is a glimpse into what computing looked like back then. What programmers had to work with (and mind you the book uses high level languages, not assembly). We've come a long way.
  
  This was well worth reading.
• 
  Stijn

  Until page 58 the "elements of programming style" rules mostly deal with outdated language-specific issues (`goto`s anyone?). So while I truly wanted to like this book (I love
  UNIX: A History and a Memoir by
  Brian W. Kernighan of K&R fame), this could use an update. And maybe after updating, it gets smaller. From its current 168 pages to the 105 pages (in the edition I own) of the one-and-only
  The Elements of Style.
• 
  Thiago

  3 stars because it’s quite dated, full of FORTRAN and PL/I examples. Nonetheless it has a great collection of programming principles, akin to Effective Java by Joshua Bloch, and How to Solve it by George Pólya. TL;DR: Keep it readable and simple.
  
  > Don’t comment / document bad code, rewrite it instead.
• 
  Ivan Dimitrov

  Good small book but with a bit outdated advises. If you are an adventures type - go and read it, you will not regret it, but keep in mind that all of the examples are in FORTRAN or PL/1 (which for me that was an issue when trying to understand the examples).
• 
  Seth

  This was a fascinating read (almost, but not quite, enough to make me go out and learn FORTRAN and PL/I...). As much as anything it codified and articulated clearly a set of good programming practices that I have intuited over the years. To be perfectly honest, I don't get why I was never assigned a reading like this earlier --
  Kernighan does a great job articulating the complex rationale behind reasonable design and programming decisions.
• 
  Christian

  The book is well written and clear. Unfortunately, the obsolete languages used and their inherent problems make the issues tackled by this book irrelevant.
• 
  Scott

  this mostly applies to C
• 
  David Octavia

  Another great read.
• 
  Qingwei Zhang

  those rules so helpful.