Book Review: The Practice of Programming

The Practice of Programming by Brian Kernighan and Rob Pike left me a little disappointed. If I had read it at a time closer to when it was originally published in 1999, I may have come away liking the book better. There's nothing wrong with the advice, and it reads well, but I don't think the examples are standing the test of time.

It is also possible that I'm just not a good representative of the target audience. The book focuses a lot on C, C++, and Java, with most of the examples in C. By 1999 I had moved over to mostly Python development and wasn't doing the sort of low-level coding in C that may have made their examples more appealing.

This book is about the practice of programming -- how to write programs for real.

The sections that talk about the the social aspects of programming are still valuable advice. For example, The code style issues and recommendations in chapter 1 can apply to any language, and basically boil down to write simple code meant to be read by another human being. I agree with their premise that clear code is also frequently the most optimal for runtime performance.

Chapter two talks about data structures and algorithms and covers a simple implementation of quicksort. The explanation is good, but on the other hand, does anyone still need to write their own sort functions? Do we really not have any other algorithms that are complex enough to be interesting, common enough to be worth reading about, and understood well enough that we can analyze them? I found that Beautiful Code (O'Reilly) had more interesting examples.

The Markov chain generator in chapter three did remind me of some code I wrote in 1998 (in Python) to find phrases in a Framemaker document that might be worth adding to the index. Maybe I should recreate some of that code for Sphinx.

I skimmed over a lot of the performance section since it seemed focused on low level C code and I try to avoid the sorts of situations where I would need to implement my own version of strstr() just to create a spam filter. This was another example of the text being dated.

I think the only real disagreement I had with anything they said was in the section on debugging and error handling, where the authors suggest saving exceptions for "truly exceptional" situations and don't think failing to open a file qualifies. I see two problems with this position: First, failing to raise an exception means there are two error reporting channels that need to be handled separately. Second, low-level code would have to check for all error conditions instead of allowing the exception to bubble up. Moving all error reporting to exceptions means that low-level code is more streamlined (and easier to read) because it doesn't have to consider error handling unless it can work around the problem (creating a missing file, for example). Maybe the advice is based on bad exception support in C++/Java? Or maybe their selected example is just not good. Searching for a substring may have been a better choice for an example, since the missing value isn't actually an error.

If you're new to professional programming, this book might be useful. If you have some real-world experience under your belt, you will find the same advice elsewhere in a more modern form. This book does talk about "how to write programs for real", just not the sorts of programs I have ended up writing.