Comments

Methods should have javadoc comments explaining the behavior, parameters (using @param tags or otherwise), and return type.
Methods that return non-void values must describe them in their Javadoc comment either with a “@return” tag or in a phrase in running text that contains the word “return”, “returning”, or “returns”.
Each Javadoc comment must start with a properly formed sentence, starting with a capital letter and ending with a period.

Basic information that are better contained in a javadoc comment.

Identifiers

Names of static final constants must be in all capitals (e.g., RED, DEFAULT_NAME).
Names of parameters, local variables, and methods must start with a lower-case letter (Camel-Case Style), or consist of a single, upper-case letter.
Names of types (classes), including type parameters, must start with a capital letter.
Names of packages must start with a lower-case letter.
Names of instance variables and non-final class (static) variables must start with either a lower-case letter or “_”.

Do not use ‘import PACKAGE.’, unless the package is java.lang.Math, java.lang.Double, or org.junit.Assert. ‘import static CLASS.’ is OK.
Do not import classes or members that you do not use.

Write any modifiers for methods, classes, or fields in the following order:

Do not explicitly modify methods, fields, or classes where the modification is redundant:

Do not label methods in interfaces or annotations as “public” or “abstract”
Do not label fields in interfaces or annotations as “static”, “public”, or “final”.
Do not label methods in final classes as “final”.
Do not label nested interfaces “static”.

Only static final fields of classes may be public. Other fields must be private or protected.

Classes that have only static methods and fields must not have a public (or defaulted) constructor.

Classes that have only private constructors must be declared “final”.

Local variables and parameters must not shadow field names. The preferred way to handle, e.g., getter/setter methods that simply control a field is to prefix the field name with “_”, as in
```
public double getWidth() {
     return _width;
}

public void setWidth(double width) {
    _width = width;
}
```
Do not use nested assignments, such as “if ((x = next()) != null) …”. Although this can be useful in C, it is almost never necessary in Java.
End every arm of a “switch” statement either with a “break” statement or a comment of the form
```
/* fall through */
```