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.