Code Review Checklist

Greytip Software

Code Review Checklists

The goal of the review checklist is to facilitate the evaluation of the following aspects of
the code to determine whether: the code is defect-free (no logic and maintenance
errors); the code matches the design; and the code matches the requirements (no
unnecessary features, or features that don't meet the requirements).

1) Understandability
a. Do you understand the code? Does a method definition comment
document which of its parameters the method is going to change?
b. Are the comments accurate?
c. Are the names of the variables meaningful?
d. If the program language allows mixed case names, are the variables
named with confusing use of lower case letters and capital letters?
e. Are there similar sounding names? (May lead to unintended errors.)
f. Is sufficient attention being paid to readability issues like indentation of code?
2) Maintainability
a. Are the comments necessary?

b. Are variable names spelled consistently?
c. Are variables documented with (where it's not obvious): units of
measure, bounds, and legal values?
d. Are command-line arguments and environment variables documented?
e. Is user-visible functionality described in the user documentation?
f. Does the implementation match the documentation?
g. Are changes described?
h. Are the variables initialized?
i. Is the access of data from any standard file, repositories or
database done through publicly supported interface?
j. Are all the conditional paths reachable?
k. Is there any part of code that is unreachable?
l. Are there any loops that will never execute?
m. Is there usage of specific idiosyncrasies of particular machine architecture or a
given version of an underlying product (e.g., using "undocumented" features)?
n. Are the sections of code (i.e., methods, classes, enums, etc.) small
enough to be reasonable?
o. Is the code adequately documented, especially where the logic is
complex or the section of code is critical for product functioning?
p. Are the interfaces and the parameters thereof properly documented?
q. Are exceptions handled and logged?
r. Are error messages written in a standard format?
Page 1 of 4
Version 0.3
s. Are Javadoc tags used to document comments the code?

http://www.oracle.com/technetwork/java/javase/documentation/index-
137868. html
3) OO best practices
a. Proper use of OO concepts :

i. Abstraction — essential characteristics of an object are
identified; an emphasis is placed on what an object is or does
rather than how it is represented or how it works.
ii. Class — code is organized into functional units; for example, the
UI code is in one class, and code that responds to the UI
interactions is in another class.
iii. Encapsulation — related data and methods are packaged
together. The data inside an object is accessed only by its
methods. Get/Set methods are used for private attributes.
iv. Inheritance — base classes are created, base classes are
extended and use their methods are used or functionality
(customized behavior) is added to them.
v. Polymorphism — methods that take other objects as parameters
are defined. An operation may exhibit different behaviors
depending on the data types used in the operation.
b. Loose Coupling between classes for more flexible, extensible software —
Use of coupling factors should be minimized. Strong coupling means that
one object is strongly coupled with the implementation details of another
object. Strong coupling is discouraged because it results in less flexible,
less scalable application software.
i. Coupling: when one object interacts with another object
ii. Law of Demeter - a.k.a. Principle of Least Knowledge: Only talk
to your friends
Any method M of an object O may only invoke the methods
of the following kinds of objects:
itself
its arguments/parameters
any objects it creates/instantiates
its direct component objects
c. High Cohesion —
i. A cohesive design can allow for optimizations like lazy loading (i.e.,
object initialization is deferred until it is needed) or caching that wouldn’t
be possible if the functionality were still spread across the application.
ii. Cohesion has been violated when an object’s function does not use any of
the object’s data, when an object contains data that is not used by its
Page 2 of 4
Version 0.3
own functions, or when an object has a function that deals only

with the data of some other object; when a function deals with
some of its object’s data but deals also with the data or functions
exposed by another object.
iii. A certain class performs a set of closely related actions. A lack of
cohesion means that a class is performing several unrelated tasks.
iv. A cohesive class is a well-structured class, it has one main job.
d. Single Responsibility Principle (SRP) — "A class should have only one
and one reason to change”. Each class will handle one responsibility.
e. Open-Closed Principle (OCP) — Classes, modules and functions
should be open for extension but closed for modifications.
f. Liskov Substitution Principle (LSP) — "In class hierarchies, it should be
possible to treat a specialized object as if it were a base class object."
i. Derived classes, i.e., subclasses, must be substitutable for their
base classes, "meaning that clients that use references to base
classes must be able to use the objects of derived classes without
knowing them. This principle is essentially a generalization of a
'design by contract' approach that specifies that a polymorphic
method of a subclass can only replace its pre-condition by a
weaker one and its post-condition by a stronger one."
ii. “If you have base class BASE and subclasses SUB1 and SUB2, the rest of
your code should always refer to BASE Not SUB1 or SUB2”.
g. Interface Segregation Principle (ISP) — “The dependency of one class to
another one, should depend on the smallest possible interface.”
i. Make fine grained interfaces that are client specific. It means multiple
client-specific interfaces are better than one general-purpose interface.
h. Dependency Inversion Principle (DIP) — “Higher level modules
should not depend on the details of the low level modules. Both
should depend upon abstractions.”
i. Abstractions shouldn't depend upon details. Details should
depend upon abstractions.
ii. Avoid designs that are
difficult to change because every change affects too many
other parts of the system
difficult to reuse in another application because it cannot be

disentangled from the current application due to
implicit dependencies on current code
4) Adherence to Coding standards
Page 3 of 4
Version 0.3
a. Does the code follow widely accepted coding standard? For example, Code
Conventions for the Java Programming Language.
http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-
1 36057.html
b. Are values being assigned to variables of the corresponding data types?
c. If there is a nested if statement, are the then and else parts
appropriately delimited?
d. In the case of a multi-way branch, such as a switch-case statement, is
a default clause provided? Are the breaks after each case appropriate?
e. Are there any loops where the final condition will never be met and hence
cause the program to go into an infinite loop?
f. Does the code follow any coding conventions that are platform specific?
g. Are "unhealthy" programming constructs (e.g., global variables in C)
being used in the program?
h. Are resources released?
i. Is exception handling used correctly? For example, no empty catch, no
generic exceptions, no losing of stack trace, no losing inner exception
j. Is every public method justifiably public, e.g., not by accident or for testing?
5) Potential for code reuse

a. Robustness—
i. Applications capture critical errors and send alerts to operators.
ii. Software is designed to restart services experiencing a
failure automatically and resume operations transparently.
iii. Processes' activities are continuously monitored. Alerts are
automatically issued for any process that appears to be inactive,
stalled, or performing below expected levels.
b. Avoid code duplication — achieved by abstracting common methods,
algorithms and data structures and placing them in a single location. Do
not abstract code that will not be used more than once.
c. Code complexity — what is the level of nesting of the conditional
statements? Can the code be simplified to reduce complexity?
Page 4 of 4

Code Review Checklist

Uploaded by

Copyright:

Available Formats

Code Review Checklist

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Code Review Checklist

Uploaded by

Copyright:

Available Formats

Greytip Software

Code Review Checklists

a. Are the comments necessary?

s. Are Javadoc tags used to document comments the code?

a. Proper use of OO concepts :

own functions, or when an object has a function that deals only

difficult to reuse in another application because it cannot be

4) Adherence to Coding standards

5) Potential for code reuse

You might also like