The Elements of Java™ Style (SIGS Reference Library, Series Number 15)

A concise vivid work on implementing a practical and useful style for the Java programming language. I used it extensively in my own programming understakings. I proposed it for taking it as model for many software projects in our company. They used it for establishing their own rules and styles for the coding processes.

This is a fine guide to style, but it crosses the line into methodology in places that are misleading at best, and simply wrong at worst.Example: Principle 73, "Wrap general-purpose classes that operate on java.lang.Object to provide static type checking," provides a perfectly functional example of how a type-specific wrapper can impose type-checking on a collection designed for the overall parent class, Object. But the book was written in 2000, and in 2004, the addition of generics to Java rendered this technique obsolete. It still works, but no one would do it that way anymore.Example: Principle 99, "Use the double-check pattern for synchronized initialization," sets forth a once-popular, but now debunked, idiom for limiting initialization to one thread. See Brian Goetz's article, "Double-checked locking: Clever, but broken," for a clear explanation as to why the Java Memory Model allows this method to fail (and note that Goetz specifically points out that this book erroneously endorses it).Example: Principle 103, "Leave optimization for last," is hard to reconcile with Principle 102, "Reinitialize and reuse objects to avoid new object construction." It's hard to leave the use of 102 out of your initial design, yet 103 advises you to do just that (same conflict with 103 exists for Principles 38, 67, and 100).There are a few oddities to the good parts, too. For example, they recommend using two spaces for each level of horizontal indentation. The wider practice appears to be to use four. They recommend opening braces at the end of a line, with closing braces on a line by themselves at the same column as the first character of the line with the matching opening brace. That's probably the most widely followed pattern, but Allman-style (the opening brace goes under that first character) is a good choice too, especially if you (like me) learned in a language that used "begin" and "end" instead of "{" and "}." Now, nothing is more certain to provoke a red-faced, fists-clenched, pistols-at-dawn dispute between programmers than the question of where the opening brace goes, but a style guide ought to at least have acknowledged that Allman-style exists.All in all, I think this book would be a good basis for your own shop's style guide. But I wouldn't rely on its example code at all, and I would encourage your team to get together after reading it, agree on what to change, and just write your own preferences in the margins. The true virtue of most stylistic choices comes not from what they are, but from the fact that everyone uses the same ones. Think of this book as the abstract class of style, and derive your concrete style from that.

I am very satisfied with the way this book is written. It is compact and to the point. It fulfills the requirements of an industrial Java developer and can be used as the basis for a coding convention.Harry Sneed, Software Reengineer

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.

Read Code Complete by Steve McConnell. You don't need this book. It contradicts itself on several occasions and is totally wrong on others. It's unfortunate and sad how many organizations want to adopt texts like this as their "coding standard". A pamplet-sized book of bullet-points can't make developers competent, but a comprehensive manual of the best in software engineering practices like Code Complete can.

I borrowed this book from a library several times and was impressed with it. So when I saw the chance to grab my very own copy for my personal library of books, I jumped at it. Thank you.

I'm very disappointed at the amount content in this Book. Sun posted a Java style guide that was essentially the equivalent, but free. Equivalent in terms of topics covered while there were some noticable difference such as variable naming.One of the redeming qualities of the book though is that it can serve as a coding standard thus saving one from tidious chore of deciding on your own standards. In the end does it really make that much of a difference as long as everyone on your team is following the same standard?Best part of the book is the title.

プログラマー個人に示唆を与えるだけでなく、開発チームのコーディング基準とかコーディングガイドラインそのものです。このような基準類もメインフレームの頃は自社でコストをかけて策定できたものですが今じゃちょっとそれができる会社も少ないですね。もし自分の開発チームにJavaのコーディングガイドラインが無いならば、この本から選んで作れば早いと思いました。著者の一人であるamblerが、自身のHPで公開しているものよりもずっと洗練されていますので、そちらを見ていらないと思っている方も買っても損ではありません。

Too old to be read. Returned.