1.1 Use meaningful names.

Use descriptive names for all identifiers (names of classes, variables and methods). Avoid ambiguity. Avoid abbreviations. Simple mutator methods should be named setSomething(...). Simple accessor methods should be named getSomething(...). Accessor methods with boolean return values are often called isSomething(...), for example, isEmpty(...).

1.2 Class names start with a capital letter.

1.3 Class names are singular nouns.

1.4 Method and variable names start with lowercase letters.

All three - class, method and variable names - use capital letters in the middle to increase readability of compound identifiers, e.g. numberOfItems.

1.5 Constants are written in UPPERCASE.

Constants may use underscores to indicate compound identifiers: MAXIMUM_SIZE

2.1 One level of indentation is four spaces or one tab.

2.2 All statements within a block are indented one level.

2.3 Use of braces must be consistent.

2.4 Always use braces in control structures

Braces are used in if-statements and loops even if the body is only a single statement.

2.5 Use a space before the opening brace of a control structure's block.

2.6 Use a space around operators.

3.1 Every class has a Javadoc class comment at the top.

The class comment contains at least
- the file name and/or related identifying information including, if applicable, copyright information
- a general description of the class
- course related information
- the author's name(s) in Javadoc format
- a version comment (Javadoc format) providing at least the date - note that several version comments are permitted.

Every person who has contributed to the class has to be named as an author or has to be otherwise appropriately credited.

A version number can be a simple number, a date, or other formats. The important thing is that a reader must be able to recognize if two versions are not the same, and be able to determine which one is newer.

Immediately follow each file header with:
-The package name.
- The import list.

Example:

/**
   File: Convert.java

   Contents: Class to convert Celsius to Fahrenheit or vice versa

   Course Info: CS 2631, Lab 1, Question 2

   @author Jane Doe
   @version 2011-01-01
**/

package demo;
import java.util.NoSuchElementException;

3.2 Every method has a method comment.

3.3 Element comments must be Javadoc-readable.

Class, constructor and method comments must be recognized by Javadoc. In other words: they should start with the comment symbol /**.

3.4 Comment code (only) where necessary.

Comments in code should be included where the code is non obvious. However, code should obvious where possible. Clarity is preferred over brevity. Obfuscated code is not clever, it is bad practice. Do not comment obvious statements - assume your reader is a programmer.

3.5 Block end comments are required for any block of more than a few lines. The following is unreadable:

                }
            }
        }
    }

4.1 Order of declarations: fields, constructors, methods.

The elements of a class definition appear (if present) in the following order: package statement; import statements; class comment; class header; field definitions; constructors; methods.

4.2 Fields may not be public (except for final fields).

4.3 An access modifier is required.

Specify all fields and methods as either private, public, or protected. Never use default (package private) access.

4.4 Where feasible, import classes separately.

Import statements explicitly naming every class are preferred over importing whole packages. E.g.

import java.util.ArrayList;
import java.util.HashSet;

is better than

import java.util.*;

4.5 A constructor is required (even if the body is empty).

4.6 A superclass constructor call is required (except for Object).

In constructors of subclasses, do not rely on automatic insertion of a superclass call. Include the super(...) call explicitly, even if it would work without it.

4.7 Initialize all fields in the constructor.

5.1 Use iterators with collections.

To iterate over a collection, use iterators, not int indices.

 

Modified, as permitted, from the BlueJ programming style guide, copyright by Michael Kölling and David Barnes. .