Whither Programming Style?

Good books don’t have to be brief, but two great books on writing are: William Strunk and E.B. White’s The Elements of Style, and Brian Kernighan and P.J. Plauger’s The Elements of Programming Style  – a scintillating 92 pages for Style (3rd edition), and a brisk 166 pages for Programming Style (2nd edition).

Kernighan and Plauger’s titular reference to Strunk and White’s Style reflects the almost-obvious idea that programming is writing.  And good programming, as a subset of good writing, communicates ideas with clarity.  Not particularly to computers, which do not care about ideas, but to other developers and ideally to a larger community of interested people.

It’s easy to forget this as we hurriedly sling bytes to and fro, trying to compel obedience from obstinate data systems.  I often encounter “code” or “script” rather than “programming” – writing that is machine-oriented, propelled by our immediate desire to execute a sequence of computer tasks.  Each step might make sense, but the larger context quickly becomes garbled.   And that’s a problem – obtaining good answers from data is challenging enough, without the additional difficulty of trying to understand – even from our own writing – what we’ve done to accomplish that end.  If we can’t readily understand our code, what are the chances it will do what it should?

Data-system vendors play a role in the problem, by providing scripting environments that are rudimentary, but also satisfyingly conducive to nominal progress.  Look mom! I loaded the table and put up a bar chart!  That’s great for simple problems, of which there are almost none, but encumbering for the realistic problems we actually address.

Nonetheless, good writing transcends environments and languages. I like Programming Style in part because it is now an old book. It precedes the advent of object-oriented programming, and features examples in Fortran, which is now confined primarily to scientific programming circles. But reading the book again, the concepts remain clear and fully valid. Then as now: programming is writing, and good programming is good writing. Higher level concepts such as object-orientation – also frequently absent from data system programming – play important roles for scaling, clarity, and reusability, but everything starts with the quality of our writing.  When we’re programming, we’re talking to machines, but we’re writing for people.  It takes longer to program well, but it is less expensive than misunderstanding and confusion.

One of my favorite ideas from Programming Style is what Kernighan and Plauger call the “telephone test.”  If we can read our code over the phone to someone and they understand it, the code is clear.  If not, it needs re-writing.    A favorite idea, but for a lot of what we do, also a sobering one.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s