By Chris Douce
by Allan Vermeulen et. al.
Cambridge University Press, 2000
The title of this short pocket book has been derived from Kernighan and Plauger's classic 'Elements of Programming Style' published back in 1978. Despite a second edition of the book being published in eighty-nine, I found that it was an incredibly difficult book to get hold of.
The issue of programming style was one of the many that led me to the area of the psychology of programming. Very early in my programming career I discovered that a number of developers around me were using different formatting conventions. Like many before me, I became incredibly irritable when presented with the rigors of Fortran which required certain characters to be in particular column positions - something to do with punched cards, apparently.
I decided there were a number of dimensions of style: naming, white space, function size, use of declarations. Was there such an issue as an 'optimal' style, I wondered? Is there a form that allows programming error to be minimised?
Styles are like habits. They can be formed by technology, by sweat through syntactic rigor. I am sure that many of us would have heard of software folklore stories (see also Lindsay Marshall's PPIG'02 paper) about an old programmer who insisted on writing line numbers, even though the compiler no longer supported them.
Recently, I found myself challenged. 'Why don't you put your assignments and declarations together? This reduces lines of code!' Embarrassed, I came to realise that this was due to my Pascal upbringing, and the pickiness of its compiler for efficiency reasons. My style, it seemed, was to some degree static due to programming indoctrination, my sense of aesthetics not moving with the programming times.
This is a book that can be read in around two hours, but its digestion will take considerably longer. It begins with truisms like, 'use familiar names' and 'question excessively long names', to good object-oriented advice such as 'use nouns when naming classes' and 'make object methods carry out only one operation'.
There are some elements that I take objection to - the use of curly braces, for example, and the adoption of two space characters per indent instead of one tab (an explanation is offered, but one that I'm not convinced about!). Using this offends my senses. I prefer my own idiom.
The authors are pragmatic about comments. They ask you to use comments so that automatic documentation can be formed from source code through the documentation of classes and interfaces. They also insist that comments should reflect codebase reality, using the third-person narrative form, and to illustrate (with references, perhaps) why the code is doing what it is doing, not what it is doing.
A number of familiar references are provided, along with a range of web links. Writing Solid Code by Maguire and Code Complete by McConnell both make an appearance.
The Elements of Java Style strikes me as a miniature refactoring text, especially when it addresses some object-oriented issues. Whilst getting hot under the collar about their bracketing (and naming) conventions, I remember what a colleague said to me a couple of weeks ago when he asked me to review some Java code that he was battling with: 'I don't care what the programming style is - as long as it is consistent', and don't come across comments like, 'this appears to work, but I do not know why'.
Second hand copies of the The Elements of Programming Style can now be found on Amazon.
Have you read a book that you think that others may find interesting? If so, please do tell us about it. We're crying out for some reviews of psychology books! Send us your reviews and ideas.