Code Review Checklist

Project Name
Version

The Code Review Checklist provides a company guideline for checking code including pass/fail
parameters and recording any comments when the test fails.

During a project, this document is used by team members as follows:

1 During project planning, it is utilized as a reminder for how much review time should
be allocated during the project for the software being developed
2 During design and development (coding) portion of the project, the checklists are
used to conduct code reviews.
The list of test items is representative and should be modified prior to use to reflect your
development environment and standards.

Generic Checklist for Code Reviews

Structure
Description of Item Pass Fail Comments

Does the code completely and correctly implement

the design?
Does the code conform to any pertinent coding
standards?
Is the code well-structured, consistent in style, and
consistently formatted?
Are there any uncalled or unneeded procedures or
any unreachable code?
Are there any leftover stubs or test routines in the
code?
Can any code be replaced by calls to external
reusable components or library functions?
Are there any blocks of repeated code that could
be condensed into a single procedure?
Is storage use efficient?
Are symbolics used rather than “magic number”
constants or string constants?
Are any modules excessively complex and should
be restructured or split into multiple routines?

Documentation
Description of Item Pass Fail Comments
Is the code clearly and adequately documented

Confidential – ©2015 Documentation Consultants (www.SDLCforms.com) Document: 4400 Page 1 of 9

 Code Review Checklist
Project Name
Version

with an easy-to-maintain commenting style?

Are all comments consistent with the code?

Variables
Description of Item Pass Fail Comments
Are all variables properly defined with meaningful,
consistent, and clear names?
Do all assigned variables have proper type
consistency or casting?
Are there any redundant or unused variables?

Style
Description of Item Pass Fail Comments
Does the code follow the style guide for this
project?
Is the header information for each file and each
function descriptive enough?
Is there an appropriate amount of comments?
(frequency, location, and level of detail)
Is the code well structured? (typographically and
functionally)
Are the variable and function names descriptive
and consistent in style?
Are "magic numbers" avoided? (use named
constants rather than numbers)
Is there any “dead code” (commented out code or
unreachable code) that should be removed?
Is it possible to remove any of the assembly
language code, if present?
Is the code too tricky? (Did you have to think hard
to understand what it does?)
Did you have to ask the author what the code
does? (code should be self-explanatory)

Architecture
Description of Item Pass Fail Comments
Is the function too long? (e.g., longer than fits on
one printed page)
Can this code be reused? Should it be reusing
something else?

Confidential – ©2015 Documentation Consultants (www.SDLCforms.com) Document: 4400 Page 2 of 9

 Code Review Checklist
Project Name
Version

Is there minimal use of global variables? Do all

variables have minimum scope?
Are classes and functions that are doing related
things grouped appropriately? (cohesion)
Is the code portable? (especially variable sizes,
e.g., “int32” instead of “long”)
Are specific types used when possible? (e.g.,
“unsigned” and typedef, not just "int")
Are there any if/else structures nested more than
two deep? (consecutive “else if” is OK)
Are there nested switch or case statements? (they
should never be nested)

Arithmetic Operations
Description of Item Pass Fail Comments
Does the code avoid comparing floating-point
numbers for equality?
Does the code systematically prevent rounding
errors?
Does the code avoid additions and subtractions on
numbers with greatly different magnitudes?
Are divisors tested for zero or noise?

Loops and Branches

Description of Item Pass Fail Comments
Are all loops, branches, and logic constructs
complete, correct, and properly nested?
Are the most common cases tested first in IF- -
ELSEIF chains?
Are all cases covered in an IF- -ELSEIF or CASE
block, including ELSE or DEFAULT clauses?
Does every case statement have a default?
Are loop termination conditions obvious and
invariably achievable?
Are indexes or subscripts properly initialized, just
prior to the loop?
Can any statements that are enclosed within loops
be placed outside the loops?
Does the code in the loop avoid manipulating the
index variable or using it upon exit from the loop?

Confidential – ©2015 Documentation Consultants (www.SDLCforms.com) Document: 4400 Page 3 of 9

 Code Review Checklist
Project Name
Version

Defensive Programming
Description of Item Pass Fail Comments
Are indexes, pointers, and subscripts tested
against array, record, or file bounds?
Are imported data and input arguments tested for
validity and completeness?
Are all output variables assigned?
Are the correct data operated on in each
statement?
Is every memory allocation deallocated?
Are timeouts or error traps used for external
device accesses?
Are files checked for existence before attempting
to access them?
Are all files and devices left in the correct state
upon program termination?

Maintainability
Description of Item Pass Fail Comments
Does the code make sense?
Does the code comply with the accepted Coding
Conventions?
Does the code comply with the accepted Best
Practices?
Does the code comply with the accepted Comment
Conventions?
Is the commenting clear and adequate? (As a
guide, each file will have a comment at the start,
explaining what the code does, possibly a
comment at the start of each function, and
comments as needed to explain complex or
obfuscated code.)
Are ideas presented clearly in the code?
Is encapsulation done properly?
Is the code not too complex?
Are there no unnecessary global variables?
Is the reading order in source code from top to
bottom?
Are there unused variables or functions?

Confidential – ©2015 Documentation Consultants (www.SDLCforms.com) Document: 4400 Page 4 of 9

 Code Review Checklist
Project Name
Version

Requirements and Functionality

Description of Item Pass Fail Comments
Does the code match the requirements,
specifications and standards?
Is the logic proper? Does the code function as
needed?

System and Library Calls

Description of Item Pass Fail Comments
Do all system calls have their return status
checked?
Are all possible errors from system or library calls
handled?
Are signals caught and handled?
Is mutex() used on multithreaded code on global
variables?

Reusability
Description of Item Pass Fail Comments
Are all available libraries being used effectively?
Are available openmrs util methods known and
used?
Is the code as generalized/abstracted as it could
be?
Is the code a candidate for reusability?

Robustness
Description of Item Pass Fail Comments
Are all parameters checked?
Are error conditions caught?
Is there a default case in all switch statements?
Is there non-reentrant code in dangerous places?
Is the usage of macros proper? (Readability,
complexity, portability…)
Is there unnecessary optimization that may hinder
maintainability?

Confidential – ©2015 Documentation Consultants (www.SDLCforms.com) Document: 4400 Page 5 of 9

 Code Review Checklist
Project Name
Version

Security
Description of Item Pass Fail Comments
Does the code appear to pose a security concern?
Do Service methods have an @Authorize
annotation on them
Does the application use an inclusion list (known,
valid, and safe input) rather than an inclusion list
(rejecting known malicious or dangerous input)
Is all user input encoding set by the server?
Is all character encoding set by the server?
If cookies contain sensitive data, are they marked
secure?
Do input surfaces in Web parts and other
customizations include boundary checks, input
data integrity checks, and appropriate exception
handling to protect from cross-site scripting and
SQL injection.
Does the design address potential
canonicalization issues?

Control Structures
Description of Item Pass Fail Comments
Does the application log sensitive data in clear
text.
Sensitive data is not stored in cookies.

Sensitive data is not stored in unencrypted, hidden

form fields or query strings. It is maintained by
using server-side state management.
SSL, IPSEC with encryption, or application layer
encryption prior to transmittal is sued to protect
sensitive data during transmission.
Sensitive data is not cached. Output caching is off
by default.
Sensitive data that is transferred via email uses
S/MIME encryption or Information Rights
Management (IRM), depending upon the intended
recipient.
Does the code make use of infinite loops?
Does the loop iterate the correct number of times?

Confidential – ©2015 Documentation Consultants (www.SDLCforms.com) Document: 4400 Page 6 of 9

 Code Review Checklist
Project Name
Version

Resource Leaks
Description of Item Pass Fail Comments
Does the code release resources?
Does the code release resources more than once?
Does the code use the most efficient class when
dealing with certain resources?

Error Handling
Description of Item Pass Fail Comments
Does the code comply with the accepted Exception
Handling Conventions?
Does the code make use of exception handling?
Does the code simply catch exceptions and log
them?
Does the code catch general exception
(java.lang.Exception)?
Does the code correctly impose conditions for
"expected" values?
Are input parameters checked for proper values
(sanity checking)?
Are error return codes/exception generated and
passed back to the calling function?
Are error return codes/exceptions handled by the
calling function?
Are null pointers and negative numbers handled
properly?
Do switch statements have a default clause used
for error detection?
Are arrays checked for out of range indexing? Are
pointers similarly checked?
Is garbage collection being done properly,
especially for errors/exceptions?
Is there a chance of mathematical
overflow/underflow?
Are error conditions checked and logged? Are the
error messages/codes meaningful?
Would an error handling structure such as
try/catch be useful? (depends upon language)

Confidential – ©2015 Documentation Consultants (www.SDLCforms.com) Document: 4400 Page 7 of 9

 Code Review Checklist
Project Name
Version

Timing
Description of Item Pass Fail Comments
Is the worst case timing bounded? (no unbounded
loops, no recursion)
Are there any race conditions? (especially multi-
byte variables modified by an interrupt)
Is appropriate code thread safe and reentrant?
Are there any long-running ISRs? Are interrupts
masked for more than a few clocks?
Is priority inversion avoided or handled by the
RTOS?
Is the watchdog timer turned on? Is the watchdog
kicked only if every task is executing?
Has code readability been sacrificed for
unnecessary optimization?

Validation & Test

Description of Item Pass Fail Comments
Is the code easy to test? (How many paths are
there through the code?)
Do unit tests have 100% branch coverage? (code
should be written to make this easy)
Are the compilation and/or lint checks 100%
warning-free? (Are warnings enabled?)
Is special attention given to corner cases,
boundaries, and negative test cases?
Does the code provide convenient ways to inject
faulty conditions for testing?
Are all interfaces tested, including all exceptions?
Has the worst case resource use been validated?
(stack space, memory allocation)
Are run-time assertions being used? Are assertion
violations logged?
Is there commented out code (for testing) that
should be removed?

Confidential – ©2015 Documentation Consultants (www.SDLCforms.com) Document: 4400 Page 8 of 9

 Code Review Checklist
Project Name
Version

Hardware
Description of Item Pass Fail Comments
Do I/O operations put the hardware in a correct
state?
Are min/max timing requirements met for the
hardware interface?
Is it ensured that multi-byte hardware registers
can’t change during read/write?
Does the software ensure that the system resets
to a well defined hardware system state?
Have brownout and power loss been handled?
Is the system correctly configured for
entering/leaving sleep mode (e.g. timers)?
Have unused interrupt vectors been directed to an
error handler?
Has care been taken to avoid EEPROM
corruption? (e.g., power loss during write)

Confidential – ©2015 Documentation Consultants (www.SDLCforms.com) Document: 4400 Page 9 of 9