Java Code Style Guidelines

Besides making good use of indentation, and using meaningful names for classes, local variables, data members and methods, you should following these conventions when writing Java code:
  1. Organize each class in the following order
    1. data members: group all constants together
    2. constructors
    3. methods: it is good to create logical groupings of methods within a class; related methods should appear next to one another. One suggestion is to group methods by their general type (accessor methods, update methods, query methods), and within each group, try to have public methods precede protected precede private methods as much as possible.

  2. Class and Interface names should be capitalized. For example: 
    public class Square extends Shape implements Runnable{ 
	...
}
  3. Data members should be private. Only under unusual circumstances should data members be public or protected; instead, you should create public and protected accessor/modifier methods to read/write an object's private data members. One exception to this rule is that static final data members can be public or protected.

  4. All alphabetic characters in static final data member identifiers should be upper-case.

  5. Data member and local variable identifiers should start with lower-case alphabetic characters. If a data member's identifier is a concatenation of more than one word, then the other words making up the identifier should be capitalized. The following are examples: 
    private double area;   
private Coordinate vertices[];
private double timeOfDay;
public static final int WEDNESDAY = 3;
  6. Comment data members and constants. By using good identifier names, you can often skip comments for data members that are base types, and can group together a set of related data members or constants with one comment. For example: 
    	// dimensions of a box in inches
	private int width;
	private int height;
	private int depth;
  7. All methods should be commented with:
    1. a brief description of what the method does
    2. a description of each parameter value
    3. a description of its return values
    4. what exceptions it throws including a brief description of the condition that causes each exception to be thrown.

    One exception to this commenting rule, is for very simple methods where it is absolutely obvious from the method's name what the method does, you do not need a full method comment. For example, a simple accessor method int getXCoordinate() probably does not need a full method comment.
    You may use javadoc style comments for all public data members and methods if you'd like. However, doing so is not required. Look at section 1.9.2 in the book for more information on javadoc.

  8. All method names should start with lower-case alphabetic characters If a method name is a concatenation of more than one word, then the other words making up the name should be capitalized. For example: 
    /**  THIS IS AN EXAMPLE OF A javadoc STYLE COMMENT
 * 
 * Tests if this Day object is a week day (not a Saturday or Sunday).
 * @param msg: a message that will be printed if the day object is a week day   
 * @return true if this Day object is a week day, otherwise return false. 
 */
public boolean isAWeekDay(String msg) {
   ...
} 

// 
// Convert a String representation of a day of the week 
// to its numerical encoding 
//  param day: the day String to encode
//  returns: an numerical representation of the day String (S=0, M=1, ...) 
//  throws: NotAValidDayException if 'day' is not a valid day 
//	   of the week
//
private int dayStringToInt(String day) throws NotAValidDayException {
   ...
}

  9. Do not wrap lines. All source code lines should fill at most 80 columns. Lines that are wrapped because they are more than 80 columns long make your code very hard to read. As a result, you should never have a line longer than 80 columns wide (this includes white space).

    If you have a line that is too long, then split it into two lines with good indentation. For example, the following single println method call should be broken up into two calls to the print method or into a single call with two or more strings concatenated together: 

              previous_stmt; 
          System.out.println("This is an example of a very long string that caus
es line wrapping and should be fixed"); 
          next_stmt;
    should be replaced with: 
              previous_stmt; 
          System.out.println("This is an example of a very long string that"
                             + "caused line wrapping and now is fixed");
          next_stmt;
    For Java statments that may be longer than 80 columns, break the statement up into logical pieces each on its own line and each indented in the same way. For example: 
         for(int index = foo.GetInitialValue(); index <= foo.GetStopValue(); index +
= foo.GetStepAmount()) {
          // for loop body 
     }
    should be re-written with a carriage return between parts of the for-loop statment and each part indented so that it is clear that it is part of the for statement: 
         for(int index = foo.GetInitialValue(); 
         index <= foo.GetStopValue();
         index += foo.GetStepAmount()) 
     {
         // for loop body 
     }

    The easiest way to ensure that you do not wrap lines is to resize your editor window so that it is 80 columns wide.