The Elements of Programming Style by Brian W. Kernighan, P. J. Plauger — Summary & Review

Back in the mid-1970s, when computers were still clunky beasts and programming languages were less forgiving, Brian Kernighan and P. J. Plauger hammered out a simple truth: code should be clear, readable, and maintainable. "The Elements of Programming Style" is their attempt to turn programming from an arcane ritual into a craft anyone could respect. This book isn’t about flashy algorithms or the latest language features—it's about the timeless art of writing code that humans can understand without a decoder ring.

The authors borrow from the world of writing style guides—think Strunk and White’s "The Elements of Style"—and apply those principles to programming. The result is a collection of practical advice, illustrated with real examples from the era’s programming textbooks and their own work. The examples are mostly in older languages like Fortran and PL/I, which might feel like archaeology to modern readers. Still, the lessons shine through: clarity beats cleverness, and simplicity trumps complexity.

At its core, the book preaches that code isn’t just for computers; it’s for people. That means choosing meaningful variable names, avoiding unnecessarily convoluted control structures, and using library functions instead of reinventing the wheel. Kernighan and Plauger argue that using well-tested library routines not only saves time but also reduces bugs—good luck arguing with that in any era.

One of the biggest battles the book fights is against the notorious GOTO statement, a relic that led to tangled, unreadable code. The authors champion structured programming as a way to make code flow logically and predictably, which helps prevent the dreaded "spaghetti code" syndrome. This was a fresh perspective back then and helped push programming towards modern standards.

Documentation also gets its due. The authors stress that comments should clarify, not clutter. Redundant comments that just repeat what the code obviously does are a waste of time. Instead, comments should explain why the code does something or provide context not obvious from the code itself.

The book wraps each chapter with pithy maxims that feel like the programming equivalent of "less is more." These short nuggets pack a punch, reminding programmers that style isn’t about rules for rules’ sake but about making code easier to read, debug, and maintain.

Of course, the book isn’t without its quirks. Its focus on procedural languages and examples from the 1970s means some advice feels a bit dated, especially for those deep into object-oriented or functional programming. Modern languages and paradigms have introduced new style concerns that Kernighan and Plauger couldn’t have anticipated. Still, the fundamental ideas about clarity, simplicity, and readability remain solid ground.

For anyone who’s ever stared at a block of inscrutable code and wondered why it has to be so painful to understand, this book offers a refreshing dose of common sense. It’s less about flashy tricks and more about the steady craft of writing code that won’t haunt you or your teammates down the line. In a world where "write once, read never" still happens far too often, "The Elements of Programming Style" is a reminder that good style is a form of respect—for your code and the humans who live with it.