Kernighan & Pike's "The Practice of Programming" (TPOP) is a short book in the general-advice-on-everything-related-to-programming genre. Both authors have impressive pedigrees, predisposing one to expect much from them. This book delivers: though the focus on C and the text's conciseness might put off some readers, this is a volume that is worth reading and re-reading.
The Good: it is a sad fact that even though a work like E. H. Gombrich's "Story of Art" attracts favorable reviews from young readers and accomplished artists alike, there are many programmers who feel the need to point out that they already know everything covered in Kernighan & Pike's TPOP. Let there be no doubt about this: "The Practice of Programming" is a masterful work, containing distilled wisdom. TPOP belongs to a very short list of programming books that deserve careful reading of even the minutest detail and amply reward such effort (Jon Bentley's "Programming Pearls" is another text on this list). Kernighan & Pike's text covers every aspect of practical programming, from style, through data structures, design, debugging, testing, performance, portability, up to special-purpose languages. It authoritatively covers a huge variety of topics, bringing to mind another important text, Steve McConnell's "Code Complete", which is easier to read, more detailed, and therefore 3.5 times longer. Even so, it's interesting to note that, unlike TPOP, "Code Complete" does not include exercises and does not discuss topics like tail recursion or endianness. On a different note, any book addressing the totality of programming is bound to disappoint a fraction of its potential readers by not using the language du jour. Kernighan & Pike have tried to preempt such complaints by including some mention of C++, Java, awk, and Perl, but in its core this book is C-oriented. C is still the lingua franca of programming, so this seems appropriate; as the authors put it, C "gives the programmer complete control over implementation, and programs written in it tend to be fast." Despite the conciseness and technical nature of TPOP, the authors manage to keep things flowing without mincing their words, e.g. "a lot of quick and dirty code ends up in widely-used software, where it remains dirty and often not as quick as it should have been anyway". Intriguingly, they are equally direct when discussing C-related issues, e.g. "rather than having memcpy for speed and memmove for safety, it would be better to have one function that was always safe, and fast when it could be." They also sneak in a joke or two, e.g. an enumerator in Plan 9's errors.h is called Egreg, which would have been funny even if it wasn't followed by the inimitable comment "It's all Greg's fault".
The Bad: parts of this book are non-trivial, e.g. the interplay of split() and advquoted() in the second C version of the CSV library. I'm bringing this up in the section on "The Bad" only because it's customary to expect a lot of filler in books on programming. In reality, this is one of the good aspects of TPOP: even when things get intricate it's worth putting in the effort to figure out what's going on. To quote Faulkner's (alleged) admonition in response to the complaint that some of his works are difficult to understand even after two or three readings: "read it a fourth time!" Of course, even though Kernighan & Pike are much more competent than the average programming author, they're still human, so they do sometimes produce phrases like this one: "Well-written programs are better than badly-written ones". At a more detailed level, I did notice a few minor issues. For example, in chapter 1 the authors rewrite a Java class and then say that the new version is better because "it leads to statements like queue.capacity++". However, directly accessing and changing a member variable violates encapsulation. Still at a fine-grained level, I spotted only one issue regarding the C code (other than the need to keep a reference handy at all times). In chapter 3 the authors say that the programs they show are production code and they also state that "the C programmer must do more of the work, allocating and reclaiming memory, creating hash tables and linked lists, and the like". Given both these points, one would expect that best practices imply that malloc'ed memory should be explicitly free'd, out of respect for the maintenance programmers to follow. However, the Markov chain C program does not do this. Finally, some of what this text has to say on C++ is non-idiomatic (though almost always still correct). Kernighan & Pike matter-of-factly mention or use int main(void), strcpy, strstr, and realloc in C++. A C++ aficionado might even go so far as to note that when they do use std::string (instead of C-style strings, as in the rest of the text) they get the number of characters from [the strlen() descendant] length() instead of [the STL mainstay] size().
In a nutshell, this book is a classic and is destined to remain one. This should come as no surprise to those who've read Kernighan & Pike's earlier "The Unix Programming Environment". Highly recommended.
Alex Gezerlis
- Amazon Business : For business-only pricing, quantity discounts and FREE Shipping. Register a free business account
