Anyway, looks like these sections you're citing are pretty subject to interpretation: they say you must use one blank line here, but it doesn't say you can't use one more, do they? You had to add the word "single" to clarify what you don't like, didn't you?
Salut,
Jordi.
Boutcher, James K. wrote:
I thought my negative 1 might need some explanation:2. Adopt Sun's coding standards (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html) James K Boutcher: -1
I'm all for clean coding, and I'm also for 95% of Sun's coding
convention doc. Some of it goes a bit far, I think - and you don't want
people intimidated submitting code, right? .. A couple examples of
things I personally don't follow - and don't see why this should ever be
part of a standard:
-----
8.1 Blank Lines
Blank lines improve readability by setting off sections of code that are
logically related.
Two blank lines should always be used in the following circumstances:
* Between sections of a source file
* Between class and interface definitions
One blank line should always be used in the following circumstances:
* Between methods
* Between the local variables in a method and its first statement
* Before a block (see section 5.1.1) or single-line (see section
5.1.2) comment
* Between logical sections inside a method to improve readability
-----
Who's to tell me that *only* a single blank line should be used for
improved readability? Sometimes I use two. Sometimes three. I don't like
Sun trying to define whitespace usage.
And.. (whoa - that was 4 lines for readability!)
-----
10.5.2 Returning Values
Try to make the structure of your program match the intent. Example:
if (booleanExpression) {
return true;
} else {
return false;
}
should instead be written as
return booleanExpression;
Similarly,
if (condition) {
return x;
}
return y;
should be written as
return (condition ? x : y);
-----
I think that you should be free to use whatever method you want (mostly
the second one - which is confusing to some people!) to improve
readability.
IMHO, Sun went a bit too far. And that's why I voted negative.
Jim
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
