Customer Reviews

The Elements of Java(TM) Style (SIGS Reference Library)

5 star:		(19)
4 star:		(8)
3 star:		(4)
2 star:		(2)
1 star:		(2)

 

 

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.

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.

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!

For the most part, this book is a great style guide for Java programmers. Most Java programmers' code would benefit significantly by following the conventions listed here.

However, the book gives some bad and confusing advice. The worst advice is the double-check pattern, which is not thread-safe. Some of the other code samples in the Synchronization and Efficiency sections also look like they are not thread-safe. Another example of poor advice is rule 74: Encapsulate enumerations as classes, which doesn't point out that "null" is a valid enumeration value for all such enumerations. The code sample shown in that rule can throw NullPointerException, for example. The advice about "inner classes" is confusing, because it is obvious the advice actually applies to all nested classes, not just inner classes (non-static nested classes).

Overall, the book gives good advice to the experienced Java programmer. I can't recommend this book to the beginning Java programmer, partly because of the above reasons, but mostly because the book mentions so many aspects of the Java language it could easily overwhelm a beginner. Once you've mastered the basics of the Java language, however, this is a good book to take a look at.

This is an excellent quality work that can be used to instill quality in others. Don't bother writing up a long list of company do's and don'ts, just hand out this book. It covers coding style, documentation style, and lots of Java tips and techniques. It's exactly what I've been looking for, I just wish someone would write a similar book for HTML, XML, XSL, Transact-SQL, and all the other languages we use at work. This book is very concise, I was able to read it in a day, but it very heavily favored quality over quantity. I can't think of a tip that they left out, and every tip that needed illustration had an accompanying clear example. A perfect work and just what I've been needing.

This book is a great compilation of many many little "secrets" and techniques from real Java projects. Chapters about documetation and packaging are really really good (the later is just 6-7 pages long but those are probably the most concise 6 pages I've ever read about package designing). If you read Sun's coding style recommendations for Java (available on Sun's site) and liked it, this is the book for you. It covers all other aspects of java programming using the same style.

Having gone through school at a university where Java replaced C++ several years ago, I've had about 4-5 years experience with Java by now. And the one bad thing I'll say about this book is that if you've been programming Java for a good while, most of what's in this little book is going to sound familiar and common sense.(just look at the summary in the back of the book and you'll be nodding your head at most of the conventions)

But if you're learning Java, this book is full of subtle tips that will make your code at least look like it's been well-written. :-) Very good book describing a lot of things that experience can and will teach you, but not as nicely.

...and they didn't! It's a small book packed with Java hints and tips. A lot is common sense, in fact most of it. The trouble is that it is only common sense after someone points it out to you.

Documentation has always been an issue in our office but by agreeing and implementing he measures suggested here the issue has been greatly reduced. Like we used the book (as one component) to help get our GUI gurus to agree a common design philosophy.

We have a fair number on contractors pass through our offices and now always make sure they know where our marked up copy is when we introduce them to our development standards.

Good book.

This is a great little book. It deserves kudos for saying anything at all useful about Java in 128 pages, but the size is actually sufficient to the book's purpose. This is a great introduction to generally recommended coding practices, and an invaluable desktop reference for anyone wanting to write Java that other humans will actually be able to read and understand.

This book provides a strong basis for establishing the always needed coding standards on every project. But, just as with the classic Elements of Style, it needs an updated edition. One major note that should be addressed is the recommendation on double-checked locking - the fact that this flat out does not work in Java has been well-documented and published on multiple occasions. I look forward to the 2nd edition!