The Elements of Java Style (Paperback)

~ Allan Vermeulen (Author), Scott W. Ambler (Author), Greg Bumgardner (Author), Eldon Metz (Author), Trevor Misfeldt (Author), Jim Shur (Author), Cao Tieou (Translator), Alan Vermeulen (Author), Patrick Thompson (Author) "While it is important to write software that performs well, many other issues should concern the professional Java developer..." (more)
Key Phrases: javadoc utility, volatile classes, stable packages, Sun Microsystems, Engineering Notebook, Robert Martin (more...)

Editorial Reviews

Review

'The Elements of Java Style is perfect in what it tries to achieve. Each rule is sensible, hardly any are debatable, and there is no excuse for ignoring any of them.' JavaZone Book of the Week --This text refers to an out of print or unavailable edition of this title.

Review

"This is a great book for the beginner or intermediate developer -- experts should already know this stuff. It will help you create better, cleaner, more easily maintained code. If you work with other developers, I recommend getting several copies for the group...The Elements of Java Style proves that 'Good things come in small packages.' Physically, it's a small book, and weighs in at just 142 pages. However, the positive impact it can have on your work is all out of proportion to its size. That's because the ideas presented aren't limited to a single language, and the way the ideas are presented is very compact. The Elements of Java Style isn't about the code you write, it's about the way you write. Its central premise is that your writing style either enhances or decreases the readability and understandability of the code you write...Over the years, I've read lots of books that I would recommend to different developers, but this book is one of a few that I would recommend to all developers. Pick up a copy, give it a read, and I think you'll agree."
Javalobby

"The Elements of Java Style is a useful resource for those wishing to refine their skills in the language and apply them in a team environment."
Science Books & Films

"By and large there is little to argue about. The Elements of Java Style is perfect in what it tries to achieve."
The Development Exchange's Java Zone

See all Editorial Reviews

Product Details

• Paperback: 142 pages
• Publisher: Cambridge University Press; Reprint edition (January 2000)
• Language: English
• ISBN-10: 0521777682
• ISBN-13: 978-0521777681
• Product Dimensions: 6.8 x 4.3 x 0.4 inches
• Shipping Weight: 4 ounces (View shipping rates and policies)
• Average Customer Review: 4.2 out of 5 stars  See all reviews (33 customer reviews)
• Amazon.com Sales Rank: #177,260 in Books (See Bestsellers in Books)

• This item is part of The Cambridge Programming Elements of Style Series.

Customer Reviews

Most Helpful Customer Reviews

38 of 38 people found the following review helpful:

4.0 out of 5 stars A coding standard for every Java programmer., November 10, 2001

By	Doug Bell "Java guru" (San Diego, CA USA) - See all my reviews (REAL NAME)

A good coding standard should focus on advice that encourages the correct and consistent application of a language. The more widely-adopted a standard is, the more benefit. No less than the Java Language Specification acknowledges this by listing a limited set of naming and usage practices. While the JLS falls far short of establishing a complete coding standard, the naming conventions it established have alone been of great benefit to the Java community. The "Elements of Java Style" nicely fills the gap left by the JLS in other areas, although it too falls a little short in places--thus the 4 star rating instead of 5.

I strongly suggest "Effective Java" by Joshua Bloch as a companion to this book. Whereas the 108 rules in this book focus on style, format and many pearls of practical advice, "Effective Java" provides an excellent set of 57 rules that go much deeper and tackle more advanced aspects of writing correct and consistent code. The two books complement each other well.

Of the 108 rules, the most glaring technical error is rule #99 which promotes the use of the flawed double-check synchronization pattern. Ignore this rule.

The 108 rules are divided into six chapters as follows:

4 General Principles: While I would have added a few, the four here are quite sound.

4 Formatting Conventions: Programmers tend to get weird about code format. After long enough you realize any reasonable and consistently adhered to standard is fine, so just use this well-considered set.

23 Naming Conventions: These are of great benefit as they resolve the ambiguities left by the JLS. I especially like rule #12, "Join the vowel generation".

35 Documentation Conventions: These very well-reasoned conventions will help to produce useful documentation as well as to eliminate unnecessary or excessively wordy documentation. The rules target both internal and external documentation as emphasize the different goals of each.

37 Programming Conventions: While there is a lot of good advice in this section, it also contains some of the weakest advice. Rule #74 on enumerations is flawed ("Effective Java" provides better coverage on how to use enumeration classes). The section on using assertions (4 rules) doesn't mention the important rule to only use tests with no side effects. It will also need to be modified for the assertion facility being added in J2SE 1.4. The section on threads and synchronization is the weakest (7 rules) as it contains rule #99 as well as some weak and incomplete advice in rules #97 and #98.

5 Packaging Conventions: This section contains some good advice not just on how to organize your classes into packages, but also on how to design stable packages.

Particularly on points of style and format, individuals will find aspects of any coding standard (at least any standard they didn't author) that they disagree with. Having written several coding standards in a variety of languages, I too have some rules I would have written differently. However, the benefit of a language-wide coding standard is that if everyone follows it, then everyone benefits from that shared agreement.

My company has adopted "The Elements of Java Style" as its coding standard with as few amendments as possible. You and your company should too.

32 of 34 people found the following review helpful:

5.0 out of 5 stars An excellent guide to Java coding standards, November 30, 2000

By	Zane Parks (Livermore, CA United States) - See all my reviews

This book is the marriage of Rogue Wave Java coding standards with those of Scott Amber. Standards are formulated as brief rules with one or more paragraphs of explanation, illustration, and justification.

The first part of the book is devoted to general principles. There are just a few of these. For example, "Do it right the first time," that is, follow standards whenever you write code, even "throw-away" code.

The second part is devoted to formatting conventions. These have to do with indentation, placement of openning and closing brackets, etc. I second the prohibition against hard tabs--use spaces instead. I've seen code written in an IDE that looks bizarre when viewed in a simple text editor like vi.

The third part is devoted to naming conventions. Good naming conventions make code more nearly self-documenting. An example from this part is "Capitalize only the first letter in acronyms." For example, use "loadXmlDocument()" instead of "loadXMLDocument()," where the obvious exception is constant names which should contain only capital letters.

Java facilitates a deeper integration of code and documentation (via JavaDoc) than most programming languages. The fourth part is devoted to documentation conventions--both JavaDoc and internal comments. If you have ever struggled with the wording of a JavaDoc comment you will appreciate the authors' no-nonsense advice.

The fifth part is devoted to programming conventions. An example from this part is "Do not synchronize an entire method if the method contains significant operations that do not need synchronization," that is, use a synchronized block for the appropriate sequence of statements rather than synchronizing the whole method.

The sixth part is devoted to packaging conventions. Package naming conventions are covered in part three. An example from this part is "Maximize abstraction to maximize stability." That is, use "stable abstractions to create stable packages."

Consistently following standards such as those offered here will result in simpler, more understandable, more easily maintainable code, a worthy goal.

11 of 11 people found the following review helpful:

5.0 out of 5 stars All the right elements, February 27, 2000

By	"shawnlane" (Bristol, Bristol United Kingdom) - See all my reviews

This book came along at the right time for me. It has all the right ingedients for standardising team coding styles and developemnt methods, including simple descriptions for their use. I recommend it to those in a similar situation or those who are looking to standardise their coding approach and create best practice standards. The real plus factor is that the book is small enough to read in a day, yet useful for a life time!