Java Programming Standards and Guidelines Peer Review Checklist

  --------------- ------- ---------------- ---- ----------- ------------ ----- ----- ----------
  **Reviewer\'s                                             **Peer                    
  Name:**                                                   Review                   
                                                            Date:**                  

  **Project       ** **                                     **Project                 
  Name:**                                                   ID:**                    

                                                            Enter if                 
                                                            applicable               

  **Developer's                                 **Project                            
  Name:**                                       Lead:**                              

  **Review Files                                                                     
  & Source code**                                                                    

                                                                                     

                                                                                     

                                                                                     

  **Code                                                                             
  Approved**                                                                         
  --------------- ------- ---------------- ---- ----------- ------------ ----- ----- ----------

The following check list is to be used in the assessment of Java source
code during a peer review. Items which represent the code being reviewed
should be checked.

# General Programming Standards and Guidelines

Refer to the OHD General Programming Standards and Guidelines Peer
Review Checklist to assess the adherence to the OHD General Programming
Standards and Guidelines.

# Java Programming Standards 

Refer to the OHD Java Programming Standards and Guidelines document for
more complete descriptions and examples of the items listed below.

## File Names

\_\_\_\_ All source code files use the .java extension

\_\_\_\_ All Bytecode files use the .class extension

## Indention

\_\_\_\_ Three or four spaces are used for indentation and done so
consistently

\_\_\_\_ No tabs are used to indent

## Braces

\_\_\_\_ Consistent bracing style is used, either the "One True Bracing
Style" or the "Kernighan and Ritchie" style.

## File Organization

\_\_\_\_ Blank lines and optional comments are used to separate sections
(beginning comments, package/import statements, class/interface
declarations which include class variable/attributes declarations,
constructors, and methods).

### 2.4.1 Java Source Files

\_\_\_\_ Each Java source file contains a single public class or
interface.

\_\_\_\_ The public class is the first class or interface in the file.

### 2.4.2 Package and Import Statements

\_\_\_\_ If any package statements are needed, they should be the first
non-comment statements. Import statements follow

### 2.4.3 Class and Interface Declarations

\_\_\_\_ The class or interface declarations should be in the following
order:

1.  class/interface documentation comment

2.  class or interface statement

3.  class/interface implementation comment, if necessary

4.  class (static) variables

    a.  first public class variables

    b.  next protected class variables

    c.  next package level (no access modifier)

    d.  last private class variables

5.  instance variables

    a.  first public instance variables

    b.  next protected instance variables

    c.  next package level (no access modifier)

    d.  last private instance variables

6.  constructors

7.  Methods

\_\_\_\_ Methods are grouped by functionality rather than by scope or
accessibility.

# Java Guidelines

### Line Length

\_\_\_\_ Where practice, line length does not exceed 80 characters.

\_\_\_ When line length must exceed 80 characters, it does NOT exceed
120 characters.

### Wrapping Lines

\_\_\_\_ Line break occurs after a comma or an operator.

\_\_\_\_ Higher-level breaks are used.

\_\_\_\_ New line is aligned with the beginning of the expression at the
same level as the previous line.

### Comments

\_\_\_\_ Comments are used to adequately explain what the class,
interface, methods, and blocks of code are doing.

### Declarations

\_\_\_\_ Variables are initialized where they are declared, unless
dependent upon a computation

\_\_\_\_ Declarations appear at the beginning of blocks (A block is any
code surrounded by curly braces "{" and "}". The exception is a variable
can be declared in a for loop.

### Naming Conventions

\_\_\_\_ All class names, interface names, method names, class
variables, method variables, and constants used have meaningful names.

\_\_\_\_ If one-character variables are used, they are used only for
temporary "throwaway" variables, such as those used in for loops.

\_\_\_\_ Class names are nouns, in mixed case, with the first letter of
each word in capitalized. Examples: class Raster; , class ImageSprite;

\_\_\_\_ Interface names should be capitalized like classes.

\_\_\_\_ Method names should be verbs, with the first letter with the
first letter of each addition word capitalized. Examples:
getBackground(); computeTemperature().

\_\_\_\_ Class variables, also called attributes, are mixed case, but
begin with a '\_' followed by a lowercase first letter. All the
remaining words in the variable name start are capitalized. Examples:
\_windowHeight, timeSeriesData.

\_\_\_\_ Constants are declared using all uppercase with words separated
by an underscore. Examples: MIN_WIDTH; MAX_HEIGHT;

### Miscellaneous 

\_\_\_\_ All if , while, do-while, try-catch, and for statements that
have only one statement to execute are surrounded by curly braces.
Example:

Avoid this:

if ( condition )

doThis();

Instead do this:

if ( condition )

{

doThis();

}

\_\_\_\_ Liberal use of parenthesis is used to avoid operator precedence
problems.

\_\_\_\_ Commented out code contains a reason for being commented out
and a date it can be removed from the source file if determined it is no
longer needed.

# Reviewer\'s Comments: