Auto boutiques-francophones Simple and secure cloud storage SmartSaver Cyber Monday Deals Week in Home & Kitchen Kindle Music Deals Store SGG Countdown to Cyber Monday in Lawn & Garden

Customer Reviews

4.2 out of 5 stars28
4.2 out of 5 stars
Format: PaperbackChange
Price:$22.95+ Free shipping with Amazon Prime
Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

on April 19, 2002
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.
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!
0CommentWas this review helpful to you?YesNoReport abuse
on November 9, 2001
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.
0CommentWas this review helpful to you?YesNoReport abuse
on May 15, 2001
Two things immediately irk me in this book.
First is the sloppy K&R style that I really find irritating to debug:
public class MyClass { ... }
The curly brackets belong inline so you know where the SCOPE of the code begins and ends like this:
public class MyClass { ... }
This is much more readable and easier to figure out which brackets go with which statement, especially when you have multi-nested statements! Think of it this way if you write a pascal program you don't write it like this
procedure MouseUp(integer Xpos, integer Ypos) begin ... end;
The debate over using Tab or spaces is less irritable except when I have to modify a nested class and have to spend alot of time counting spaces when a couple tabs would have cost less time. Also when you use tabs, the block structure really stands out well. The block structure is the whole reason for using the basic C syntax, so if you bland the block by only having two space tabs and hiding the begining curly bracket, the block does not stand out. you can't see the forest for the trees.
The other complaint is the lack of Hungarian or an mention of it. Knowing the type by having it in the name of the method, var and class can save hours of time looking for the definition as well as save time naming them. iZipCode tells me right away that the zip is stored as an int and not a string.
0CommentWas this review helpful to you?YesNoReport abuse
on May 2, 2001
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.
0CommentWas this review helpful to you?YesNoReport abuse
on November 29, 2000
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.
0CommentWas this review helpful to you?YesNoReport abuse
on November 14, 2001
This book is really a set of rules for coding style. It is good for that, and has common sense rules. However for such a SMALL book, you pay a lot. The content fits in 118 pages that might be found on the web in various forms. So the value of the price is of question to me.
The benefit of purchasing the book is that it makes it handy to look up a style format if you have questions. That is usually the only time I reach for this book - most of it I have been doing for a while.
If you are trying to set a standard in your company/group/etc, and want people to have this, it would be a good one to fill the need. (It is suprising to find out how many people do not know these rules of style).
I think that this book could have been published and sold for five dollars (US) - then I would have given it 5 stars. Its price is my only issue - not its content.
0CommentWas this review helpful to you?YesNoReport abuse
on November 15, 2000
This book offers a good style reference for programmers to agree upon, enabling them to move on to focus attention on larger issues for discussion. Along with style guidelines, the book offers a good assortment of coding practice suggestions as well. Such as; lazy instantiation of objects, not creating objects that might go unused, and many more. The book consists primarily of concepts most programmers would consider common sense. However, the fact that it pools so many of these relatively simple concepts is what makes it so valuable. For work environments where people care about spending their time debating more architectural and design related issues, this book is a must to snub out any time wasting coding standards bickering. This book coupled with Dov Bulka's 'Java Performance and Scalability' are must-reads.
0CommentWas this review helpful to you?YesNoReport abuse
on July 18, 2001
This book shows rules mostly for teams or advanced Java programers; however, some parts can be useful also as a reference for starters or intermediate programers.
Those rules are not organized by levels (say, from basic to intermediate, or from simple programs to team projects), but by topics: The book has conventions on formatting, naming, documentation, programming and packaging.
Not all the rules and conventions have examples, so you must know the Java language in depth (or have experience in programming) to understand some of them.
At the end of the book you'll find a summary of all the 108 rules and a glossary. The summary is convenient for quick reference or reviewing.
It will not help you to learn programming. It is a good complement for your favorite Java manual.
0CommentWas this review helpful to you?YesNoReport abuse
In the Spring semester of 2003, I am teaching a class in software engineering and the students are creating a large program that is to be written in Java. Not all of the students are experienced in Java, so they are required to learn the language as they follow the rules of software development. At the time when the textbooks were selected, I was not aware of this book and that is unfortunate. It is an excellent quick reference to a set of rules that will point you in the direction of much cleaner and efficient Java code.
In all future classes where I am either teaching Java or having the students use Java to write large programs, this book will be a required acquisition. I have already placed it on my textbook list for software engineering in the Spring of 2004.
0CommentWas this review helpful to you?YesNoReport abuse
on September 23, 2000
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.
0CommentWas this review helpful to you?YesNoReport abuse