Code Review Checklist

Project Code: JP-ES

Version of the work product: 1.0
Reviewer(s):
Review date:
Work product' size
Effort spent on review (man-hour)

Question Yes No N/A Note

Customer notes
For SQL script:
- Design table fields and type following JP common Practice
- Send in early to get confirmation about the field name and the type
- For create table script, must include Grant Add, Update, Delete and
Create Public Synonym statement
For source code:
- Code must be optimized and have sufficient comments: Comments must
be added at the beginning of each file (Summary), and at the beginning
and the end of the blog code that we modify. The customer will do code
review very careful and will question if the code is not well comment and
efficiently written
Eg: //Developer A start on 19 Jan 2008: Modify something
…..//code change
///Developer A end

- All files changed must be recorded to the Excel file (see sample in the
document I sent previously
YYYYMMDD_PROJECTNAME_SOURCE_CODE_DELIVERABLE.xls. It’s
very important to list all files changed correctly because customer will
base on Excel file to merge code to server (biggest issue that I faced so
far)

- Must write Log frequently for easy debug by seeing the logfile (follow the
frequent of old Code)
General
Does the code follow the Coding Convention?
Is the code self-documenting? Is it possible to understand the code from
reading it?
Commenting
Are comments up to date?
Are comments clear and correct?
Do the comments focus on explaining why, and not how?
Are all surprises, exceptional cases, and work-around errors commented?

Is the purpose of each operation commented?

Are other relevant facts about each operation commented?
Source code
Does each operation have a name that describes what the operation
does?
Do the parameters have descriptive names?
Is the normal path through each operation, clearly distinguishable from
other exceptional paths?
Is the operation too long, and can it be simplified by extracting related
statements into private operations?
Is the operation too long, and can it be simplified by reducing the number
of decision points? (A decision point is a statement where the code can
take different paths, for example, if-, else-, and-, while-, and case-
statements.)
Is nesting of loops minimized?
Are the variables well named?
Is the code straightforward, and does it avoid "clever" solutions?

31e-CL/PM/HDCV/FSOFT 1/1
Are there general description for the uninterrupted software coding
paragraphs ?
Each time a coding paragraph is updated, are there also description of the
change ?
Do complicated coding paragraphs, which may cause misunderstanding
and confusion have comments and explanations ?

Are structural code paragraph indented according to the structure if it is

multi-lined.
Does the command line contain more than one command in a line

Are break sign used when the command line is too long?
Are the command lines which are linked with the previous lines indented
just as the next level ?
Are variable names different from other object names?
Are functions named in a common way?
Are global functions differentiated from local functions by name?
Does function name have meaning?
Do object names have meaning and comply with general standards of
developing tools?
Is the way of naming folders and libraries identified in designing
document?
Are Folder names and types in conformity with the content and standard
of developing tools?

* Comments
As an enhancement system this checklist is applied for the team's
source code only, not the original code provided by the customer.

* Suggestion

[ ] - Pass
[ ] - Review again
[ ] - Other

31e-CL/PM/HDCV/FSOFT 1/1