[2010-01-23] “The Practice Of Programming”

In their book “The Practice of Programming”, Brian Kernighan and Rob Pike aim to advise computer programmers on things like testing, debugging, style, performance, design, portability, etc. that they are not usually taught in computer science classes or programming courses. This is what they call the “practice” of programming. Many pick these up over the course of their careers with some trial and error; many simply don't. This is the kind of book that has lessons for both rookie and seasoned programmers and that deserves multiple readings over the course of one's career.

I first read this book about a decade back when I was a relatively-new professional programmer with a couple of years' worth experience. Reading this book again after all these years makes me appreciate the wisdom contained in these pages and agree with almost all that the authors have to say. In fact, I think this is a great approach to becoming a good programmer - learn the basics of programming, spend a couple of years writing lots of programmes for fun or profit, read books like this to improve yourself and come back to such books after several years, having applied their principles in the interim. If you read such a book immediately after learning the basics, you might not really understand the reasons behind the advice in the book and will have to just take the words of the authors at face value.

This book is a typical “Kernighan book” - it is short and to the point, the language is clear and simple, the material is logically ordered with a natural progression and some of the examples show that it is simple to implement things (e.g. a regular expression parser) that might appear hard otherwise. It is also an old-school Unix book in that it uses the command pipe-line:

grap | pic | tbl | eqn | troff -mpm

for type-setting instead of using something like a system based on TeX.

The programming languages used in this book are C, C++ and Java with an occasional sprinkling of AWK, Perl and Tcl. Most of the examples use C however and some of the advice can be considered specific to this language rather than being agnostic. That is not as bad as it seems since every serious programmer must have C in their arsenal and not be wedded to a single language or a narrow set of languages.

The book is full of pearls of wisdom that you might miss on a quick skim through it. For example, in a section on debugging a problem, the authors say:

Resist the urge to start typing; thinking is a worthwhile alternative.

When faced with a bug, most of us either fire up a debugger or start modifying our programme in the hope of making the bug go away. With experience we learn that carefully reading the code in question and thinking about it lets us resolve the issue faster and some times exposes other latent bugs. As another example, in a section on performance, the authors say:

Thus the first principle of optimization is don't.

Once again many of us spend a lot of time trying to optimise rarely-used programmes or portions of a programme that we determine to be bottlenecks based on reasoning and intuition alone. We have to ask ourselves if the programme in question is worth speeding up and then use measurements to determine the real bottlenecks. Even then, using better algorithms and data structures coupled with clean and simple code can provide greater benefits than complex code that tries to be clever.

The last chapter in the book goes into topics like creating domain-specific languages or compiling code on the fly with an emphasis on using the right language for the job. It is better to create little specialised tools that work with text files on their standard I/O streams and that can then be combined in various ways (using Unix pipes for example) to solve different problems. This is, of course, the Unix philosophy. As an example, the authors create scripts for getting the document for a given URL, removing HTML tags from a document and formatting a text document into 60-character lines (written in Tcl, Perl and AWK respectively). They then combine these scripts to create a very simple, command-line-based, “web browser” that shows a web-page as formatted plain-text.

In short, read this book if you want to be a better programmer. If you have read it in the distant past, read it once again - you might have missed some things the first time round.

Other Posts from 2010