Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
182 views

Java Programming Peer Review Checklist V 2.0

This document provides a checklist for peer reviewing Java source code. It includes guidelines for file names, indentation, braces, file organization, line length, wrapping lines, comments, declarations, and naming conventions. The checklist is to be used to assess adherence to general programming standards and Java programming standards when reviewing Java source code.

Uploaded by

austinfru7
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
182 views

Java Programming Peer Review Checklist V 2.0

This document provides a checklist for peer reviewing Java source code. It includes guidelines for file names, indentation, braces, file organization, line length, wrapping lines, comments, declarations, and naming conventions. The checklist is to be used to assess adherence to general programming standards and Java programming standards when reviewing Java source code.

Uploaded by

austinfru7
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 4

NOAA National Weather Service/OHD

Science Infusion and Software Engineering Process Group (SISEPG) Java Programming Peer
Review Checklist

Java Programming Standards and Guidelines


Peer Review Checklist
Reviewer's Name: Peer Review Date:
Project Name: Project ID:
Enter if applicable
Developers Project Lead:
Name:
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.

1. 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.

2. Java Programming Standards


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

2.1 File Names


____ All source code files use the .java extension
____ All Bytecode files use the .class extension

2.2 Indention
____ Three or four spaces are used for indentation and done so consistently
____ No tabs are used to indent

2.3 Braces
____ Consistent bracing style is used, either the preferred Allman style or the
Kernighan and Ritchie style (a.k.a, OTBS).

2.4 File Organization


____ Blank lines and optional comments are used to separate sections (beginning

1 Version 2.0
03/28/2008
NOAA National Weather Service/OHD
Science Infusion and Software Engineering Process Group (SISEPG) Java Programming Peer
Review Checklist
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 shall 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.

3. Java Guidelines
3.1 Line Length
____ Where practical, line length does not exceed 80 characters.
___ When line length must exceed 80 characters, it does NOT exceed 120 characters.

2 Version 2.0
03/28/2008
NOAA National Weather Service/OHD
Science Infusion and Software Engineering Process Group (SISEPG) Java Programming Peer
Review Checklist
3.2 Wrapping Lines
____ Line break occurs after a comma or an operator.
____ Higher-level breaks are used.
____ A new statement is aligned with the beginning of the expression at the same level
as the previous line.

3.3 Comments
____ Comments are used to adequately explain what the class, interface, methods, and
blocks of code are doing.
3.4 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.

3.5 Naming Conventions


____ All class names, interface names, method names, class variables, method variables,
and constants used have meaningful names and do what the name suggests?
____ 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 an
underscore (_) 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;

3.6 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 )

3 Version 2.0
03/28/2008
NOAA National Weather Service/OHD
Science Infusion and Software Engineering Process Group (SISEPG) Java Programming Peer
Review Checklist
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.

4. Reviewer's Comments:

4 Version 2.0
03/28/2008

You might also like