The Java language gives you all the room you need to write code that would be very
difficult for others to understand. Java also permits you to write code that is very easy
to understand. Most development teams would prefer the latter.
A style guide provides provides a map so that the code generated by a group of programmers
will be consistent and, therefore, easier to read and maintain. Many people do not care for the
style guide offered by Sun.
This document is one alternative.
This document covers most areas where there could be confusion or difference of opinion.
Areas that have never been a problem in our experience are undocumented, but we try to provide
at least one example to demonstrate proper use somewhere in the document.
<em>Reasoning: All programs work well with spaces. Most programs will mix tabs
and spaces so that some lines are indented with spaces and some with tabs. If your
tabbing is set to 4 and you share a file with someone that has tabbing set to 8,
everything comes out goofy.</em>
<em>Reasoning: Consistency is easier to read. Plus, less editing is involved
if lines of code are added or removed.</em>
<em>Reasoning: Editors and printing facilities used by most programmers can easily
handle 120 characters. Longer lines can be frustrating to work with.</em>
<em>Reasoning: Using all upper case, as traditionally done in C, is a violation of OO abstraction.
For example, a variable which starts out as a constant may be refactored later to not be a constant.</em>
<em>Reasoning: Hungarian Notation, which specifies type as part of the identifier, violates OO abstraction. Scope identification specifies scope as part of the identifier, which also violates OO abstraction.</em>
<em>Code for testing other code often needs to be able to refer to existing identifiers, but also be able to append other qualifiers to the name. This is easier to read if an additional delimiter is allowed.</em>
<em>Reasoning: Consider that the programmer looking at your code is probably examining
each method starting at the top and working down. When encountering a loop, the first
thing the programmer wants to know is what terminates the loop. If you have that logic at
the bottom, it is harder to read. Further, many less experienced programmers are not
familiar with do..while, but may be required to modify your code.</em>
<em>Reasoning: Using <code>return</code> in the middle of a method makes it difficult to
later break the method into smaller methods. It also forces the developer to consider more
than one exit point to a method. </em>
<em>Reasoning: Using <code>continue</code> makes it difficult to later break the
construct into smaller constructs or methods. It also forces the developer to consider
more than one end point for a construct. </em>
<em>Reasoning: Using <code>break</code>, other than for switch statement control, makes
it difficult to later break a construct into smaller constructs or methods. It also forces
the developer to consider more than one end point for a construct. </em>
<em>Reasoning: Compounding increment or decrement operators into
method calls or math is not clear to less experienced programmers who
may be required to modify your code.</em>