Paul Haahr / Essays / Java Style / Other Style Guides

Other Style Guides

Joshua Bloch's Effective Java is the best thing I've ever read on how to program in Java. The book is a collection of fifty-seven suggestions on how to do or not do things in Java. Bloch writes well -- the book is interesting and all the suggestions seem well motivated. I cannot recommend this book highly enough; I wish it had existed when I started writing Java code.

The Sun document feels like a much-edited version of the old Indian Hills C Style and Coding Standards.

The Java Code Conventions from JavaSoft are less useful than one might hope. These guidelines, derived from Sun's C and C++ conventions, focus on typographic issues almost to the exclusion of everything else. The style they advocate is similar to, but not quite the same as, the style found in examples in the JavaSoft books. Some aspects of the guidelines (such as where to put copyright information) are more appropriate to an in-house corporate style document than a general guide.

 

Lea also wrote the excellent Concurrent Programming in Java book for the Java Series.

Doug Lea's Draft Java Coding Standard contains a long list of great recommendations. I agree with most of these and find them well-motivated. If you read just one other style guide for Java, this is the one I'd recommend.

Peter Norvig's Infrequently Answered Questions about Java is not really a style guide, but it makes some excellent suggestions for cases where Java seems awkward to use. This is also a very good piece to read for someone who's coming to Java from another language (say C), understands the language as a specification, but feels lost in the zeitgeist of Java.

Scott Ambler's AmbySoft Java Coding Standard is also pretty good. I find these recommendations too cumbersome and I dislike Ambler's typographic style. But, he's clearly thought about how to put together big programs which are worked on by teams.

Rob Pike's Notes on Programming in C is a good contrast to Ambler's guide, advocating a more minimalist style. While I find Rob's code often too terse and typographically cryptic, his comments on complexity and consistency are on target.

Martin Fowler's valuable Refactoring covers techniques for rewriting programs with better object-oriented design and style. The parts of the book most relevant to this document help identify areas of your programs which need work.

Anyone writing object-oriented programs who hasn't read the ``Gang of Four'' Design Patterns book should pick it up right away. Patterns provide a high-level way of thinking of program structure, a useful vocabulary for discussing design, and a catalog of examples and tools which can be used off-the-shelf. Once this book has seeped into your consciousness, your programs will become more readable.

Bertrand Meyer's Object-Oriented Software Construction provides a comprehensive, opinionated discussion of object-oriented style. The book focuses on Eiffel, but is relevant to all OO languages and systems. His ideas on Design by Contract and The Principle of Uniform Reference are central to how many people (including me) think about object-oriented software.

Finally, my favorite book on programming style is a twenty year old classic which uses FORTRAN and PL/I for its examples: The Elements of Programming Style, by Brian Kernighan and P. J. Plauger. Some of it is out of date, but most of the book is concerned with general principles that endure.

Back: Idioms