>Got a few examples?
Yes. Here are a few obvious ones.
1.) Section 6.3: "Put declarations only at the beginning of blocks. (A block is any code surrounded by curly braces "{" and "}".) Don't wait to declare variables until their first use; it can confuse the unwary programmer and hamper code portability within the scope."
This statement is quite bogus. Declaring variables in the context in which they are used makes for clearer code. See Joshua Bloch's "Effective Java" for a good discussion of why minimizing the scope of variables helps make more reliable code. Furthermore, objects should not be instantiated until it's clear they are needed. And just what is an "unwary programmer"? And finally, "hamper code portability within the scope"? That is useless.
2.) Section 6.3 (bullet 2) "Open brace "{" appears at the end of the same line as the declaration statement"
Why? The trailing curly brace is what caused the readability problems in the example if-statements in Section 4.2. The opening curly brace on line by itself separates the (single line) body from the if-check. Inconsistent indentation would then not be necessary.
3.) Section 7.4 says: Note: if statements always use braces {}. Avoid the following error-prone form:
if (condition) //AVOID! THIS OMITS THE BRACES {}!
statement;
*BUT* 7.5 says: An empty for statement (one in which all the work is done in the initialization, condition, and update clauses) should have the following form:
for (initialization; condition; update);
Why should the if-statement always get braces, but not the for? That for-statement looks
alot more error-prone than the if-check with no braces.
Anyway this is a small sample of the problems with Sun's code conventions. I fully support coding standards that are clear, consistent and produce readable code. I really don't think that Sun's document does that.
Kevin