This page was migrated from a javaranch.com.jsp
Introduction
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 do provide
at least one example to demonstrate proper use somewhere in the document.
1 - Formatting
1.1 - Indentation
All indents are four spaces. All indenting is done with spaces, not tabs.
(examples and reasoning)
Matching braces are always in the same column as their construct.
(examples)
All if, while and for statements must use braces even if they control just
one statement. (reasoning)
1.2 - Spacing and Blank Lines
All identifiers are surrounded with whitespace.
(examples and reasoning)
There are a few exceptions to this rule:
(examples and reasoning)
All method names should be immediately followed by a left parenthesis.
All array dereferences should be immediately followed by a left square bracket.
The unary operator should be immediately preceded or followed by the operand.
The cast should be written with no spaces.
Use the occasional blank line within methods to break up related chunks of code.
Use one or two blank lines between all methods.
1.3 - Class Member Ordering
Keep private methods above the methods that use them and below the constructors
(even if the constructors use them).
1.4 - Maximum Line Length
Avoid making lines longer than 120 characters. If your code starts to get indented way to
the right, consider breaking your code into more methods.
(reasoning)
1.5 - Parentheses
Parentheses should be used in expressions not only to specify order of precedence,
but also to help simplify the expression. When in doubt, parenthesize.
2 - Identifiers
All identifiers use letters ('A' through 'Z' and 'a' through 'z') and numbers
('0' through '9') only. No underscores, dollar signs or non-ascii characters.
Hungarian Notation violates OO abstraction and is not to be used.
(reasoning)
2.1 - Classes and Interfaces
All class and interface identifiers will use mixed case. The first letter of
each word in the name will be uppercase, including the first letter of the name.
All other letters will be in lowercase, except in the case of an acronym,
which will be all upper case.
(examples)
2.2 - Packages
Package names will use lower case characters only. Try to keep the length under
eight (8) characters. Multi-word package names should be avoided.
(examples)
2.3 - All Other Identifiers
All other identifiers, including (but not limited to) attributes, variables, methods
and parameters will use this default naming convention. This includes
<strong>final</strong> identifiers.
The first letter of each word in the name will be uppercase, except for the
first letter of the name.
All other letters will be in lowercase, except in the case of an embedded
acronym, which will be all uppercase. Leading acronyms are all lower case.
(examples and reasoning)
3 - Coding
3.1 - Constructs to Avoid
Never use do..while.
examples and reasoning
Never use "return" in the middle of a method.
(reasoning)
Never use "continue".
(reasoning)
Never use "break" other than in a switch statement.
(reasoning)
3.2 - Do Not Compound Increment or Decrement Operators
Use an extra line for the increment or decrement.
(examples and reasoning)
3.3 - Initialization
Try to always initialize all variables when they are declared.
(examples and reasoning)
3.4 - Scope
All class attributes must always be private, except for inner classes and some final values.
4 - Self-Documenting Code
Rather than trying to document how you perform a complex algorithm, try to
make the algorithm easier to read by introducing more identifiers. This helps
in the future if the algorithm changes and the documentation does not.
(examples and reasoning)