The Practice of Programming (Addison-Wesley Professional Computing Series)

Brian Kernighan is one of the best technical writers around, and that statement is supportable in many ways; Wikipedia claims that The C Programming Language has been used as a model for technical writing, and certainly I have seen it favorably referenced in many contexts for its writing style.  Rob Pike belongs to a generation younger than Kernighan and Ritchie, but his writing rapport with Kernighan is obviously excellent; both The Practice of Programming and The Unix Programming Environment are truly excellent books, and they benefit from both Kernighan’s tight technical prose and Pike’s sense of cleanliness in solutions.  (Which is not to say that Brian Kernighan does not also have some clean technical solutions!)

That is to say, The Practice of Programming is an enjoyable book to read for its style as well as its content.  The content of the book consists of a collection of broad practices of interest to programmers, from style (what should you name your variables?  Where should you put a comment?) to environment (how should you choose a language?) to maintenance (what log messages will help you find a bug once the program is deployed?) and everything in between.  One of the strengths of the approach in this book is that it develops several examples of real code to solve problems.  It presents solutions that generate random prose using Markov chains, match spammy phrases in email, and parse Unix-style regular expressions, among others.  In addition to these solutions, the book is filled with examples of questionable code that purports to solve some problem, followed by deconstruction of the approach and the presentation of a much better solution to the same problem.

The only edition of this book was published in 1999, and it is showing its age.  In particular, it frequently mentions the popularity of Perl as a scripting language but does not address Python, Ruby, or any of the other modern languages that are popular today (as they were barely on the radar at that time!), and its treatment of Java and C++ are somewhat unfair as those languages have advanced significantly in the intervening years.  Even some of the pitfalls in C that are mentioned were corrected in C99.  Nonetheless, if one can look past the superficial staleness of some of the claims, the meaning of the material is still relevant.  The C++ STL may have matured significantly in two decades, but the ill-behaving collections and benchmarking your actual solution remain relevant even now!

Jan 2021: While reading TPoP I discovered "Writing Solid Code" (www.goodreads.com/book/show/598624.Writing_Solid_Code). Both books cover writing professional quality code in C, but they are quite different.

TPoP claims it'll teach you how to write good (C) code. What it actually does is teach you how to write C code that's good by Unix standards. That's not to say it's a bad book. The advice on debugging is good, and the whole book is a manifesto for aggressive simplicity, which is important, especially these days.

If you're considering reading this book, but don't have a lot of time, give "Writing Solid Code" a go. You'll get more bang for your buck with it.

Original review: This one's been on my reading list for ages. Like the AWK book, it's a mixed bag--what is it with Kernighan's books? On one hand, this is a very approachable, no nonsense book. You won't find philosophical musings here, just straight up (and mostly sensible) programming advice. On the other hand, as other reviewers pointed out, I'm not really sure who this book is meant for.

The first two chapters are a very C centric style guide and a spotty intro to algorithms and data structures. The most notable thing about the algorithms chapter is probably that it includes the buggy version of binary search, so readers beware. Where the book gets interesting is in the final chapters, the ones about debugging, performance and tools. There is some solid advice there that you can see come from real world experience. Even so, the chapters are very brief, so they only scratch the surface on some topics, especially in the last chapter, the one about tools and little languages. And to top it off this is all very C focused--not surprising given its authors and their background.

So is this book worth reading? Yes, but feel free to skim the first few chapters, and focus on the second half of the book. If you do all the exercises (which I admit I didn't), you'll gain quite a lot from reading it. And if there's one thing I took away from this book, it's that you should be relentless in keeping your programs simple and clear.