Rating: 
Summary: At this price you can't go wrong...
Review: ...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.
Rating: 
Summary: A coding standard for every Java programmer.
Review: 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.
Rating:
Summary: A coding standard for every Java programmer.
Review: 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.
Rating:
Summary: Good Book on Java Style
Review: 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.
Rating:
Summary: Big little book
Review: Great quick reference when it doubt/can't remember. Personal coding style is a myth and is also a dangerous practice! Good section on following java doc standards with handy performance tuning tips. Expensive...
Rating:
Summary: very brief and very handy
Review: 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.
Rating:
Summary: A handy reference for producing expert code!
Review: Hi there!
This booklet is a significant tool in achieving correct effective and easily maintainable code: 1. Specifying the way code should be written, conforming with sun's coding conventions, keeps the code readable, and Java-docs coherent.
This is especially important when writing the code in a teem, or writing components which will be later used by others. 2. Chapter 5 lists a collection of coding tips, which can quickly turn a beginner programmer into an experienced one. e.g. rule 81:
"Do not call nonfinal methods from within a constructor -
Subclasses may override nonfinal methods, and java will dispatch a call to such a method according to the actual type of the constructed object - before executing the derived constructors. This means when the constructor invokes the derived method, the derived class may be in an invalid state. To prevent this, call only final methods from the constructor. " More about the book:
(note: this booklet does not teach Java, it focuses on the way the code should be written.) The booklet is fun to use:
1. It is tiny, and fits anywhere.
2. Not intimidating - It is thin and distilled, not like those
huge books you put on the shelf and
never bother to open because you don't
know where to begin looking...
2. It is written in a simple direct logical manner:
a rule and a short explanation (with an example)
of the logic behind it.
3. Easy to locate what you are looking for.
4. every time you open it - you find something new... In short - a handy reference for producing expert code! I love it!
Rating: 
Summary: Don't bother
Review: I found the book to be very expensive for the number of pages and content that it delivers. I found the Essential Java Style book much better value and filled with more common sense pointers. ...
Rating:
Summary: Not enough
Review: 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.
Rating:
Summary: I'm reading it day-by-day
Review: If you're concerned about writing a Code that you and other people will understand,
respect and maintain - this book is for you. Some people throw out the code like
they throw clothes to laundry machine .. I personally don't like them.
Get a style, be precise and accurate, become familiar with "must-know" idioms,
read this book. Well, I'm opening it again right now.
Those who wrote it - thank you, folks ! Good job.
| 
