This appendix contains a checklist of issues that should be addressed during a

design or code review. A review is a careful critique of the design or code after it
has been completed. A review can take many forms. In a desk check, a pro-
grammer reviews his or her own work. In a walkthrough or inspection, a group
H
of people meet to examine and discuss the product. No matter what form a

review checklist
review takes, using a checklist ensures that particular issues important to creat-
ing high-quality software are not overlooked.
Reviews involve reading through a program or design to check that objects
and classes are well designed, that algorithms are implemented correctly, that
code is commented properly, and that other quality attributes of the software are
ensured. When a review is conducted as a walkthrough, the participants usually
include the author of the code, the designer (if a separate person), one or more
additional software engineers, and a person that understands the system require-
ments. Other people that might attend a walkthrough include managers and qual-
ity control personnel.
During a walkthrough, many problems usually come to light. Errors in imple-
mentation and misunderstandings about requirements are discovered. Careful
notes must be taken so that these issues can be addressed. The goal is not neces-
sarily to solve the problems in the meeting, but at least to note them for later con-
sideration. Many walkthroughs have been sidetracked by participants following
tangents concerning one particular problem.
Walkthroughs on large software projects are an absolute necessity. Unfor-
tunately, on small software projects, walkthroughs are often overlooked or dis-
missed as nonessential. The same benefits that occur in reviews of large software
projects also occur on smaller projects. They should never be considered unnec-
essary. Considerable evidence shows that as much as 70 percent of the errors in
a program can be identified during a careful walkthrough.
Before a walkthrough can begin, the people involved must be prepared. The
software or design must be complete and ready for review. The relevant docu-
mentation, such as design documents and requirements, must be gathered. The
appropriate people to attend the walkthrough must be identified and given the
documentation. By the time the meeting takes place, the participants should
have reviewed all of the provided materials and prepared constructive com-
ments and suggestions. An unsuccessful walkthrough is usually the result of a
lack of preparation.
During the walkthrough, the author often presents a brief overview of the soft-
ware or design. The author may ask the others in the meeting to concentrate on
particular areas of concern. A specific person is usually designated as a recorder
712 APPENDIX H review checklist

to capture the major questions or problems that come up. The author and review-
ers then step through the code or design in detail, bringing up concerns and iden-
tifying problems at the appropriate time. After a walkthrough, the problems and
corrective actions noted during the meeting should be summarized and presented
to the author of the code or design so that they can be addressed.
The following checklist contains specific issues that should be covered in a
review, whether conducted by yourself or in a meeting. A checklist makes the
review process systematic and prevents important issues from being overlooked.
Depending on your knowledge of software development and Java constructs,
some of the checklist issues may not be clear. Focus on those issues that you
understand and incorporate others as they become familiar.
This checklist can be augmented with other issues. Don’t hesitate to add par-
ticular topics that address your own common programming and design challenges.

review checklist
General Issues
❑ Is the design or code complete?
❑ Can any algorithms be simplified?
❑ Does the program work for all valid input?
❑ Does the program handle invalid input appropriately?
❑ Does the program do everything it is supposed to?
❑ Does the program operate under all constraints that were established?
❑ Is the API being used to its fullest extent?
❑ Have resources (such as books and the Web) been checked for published
sources of required algorithms?

Design Issues
❑ Are classes designed to encapsulate specific implementation decisions?
❑ Are classes designed to maximize reuse?
❑ Is the design modular, facilitating the inclusion of new algorithms or com-
ponents?
❑ Does each inheritance derivation represent an appropriate “is-a” relationship?
❑ Is the class hierarchy appropriate for the problem being solved?
❑ Are abstract classes used to enhance the design of the class hierarchy?
 APPENDIX H review checklist 713

❑ Are interfaces used properly in the design to maximize consistency among

classes?
❑ Are classes grouped appropriately into packages?
❑ Are exceptions used only for handling erroneous conditions or truly unusual
processing?
❑ Are threads used appropriately to minimize user response time?

Implementation Issues
❑ Are all coding standards followed?
❑ Are all comments complete and accurate?
❑ Are all variables initialized before they are used?
❑ Are constants used to make the code more readable and facilitate modifica-
tions?
❑ Are all identifiers named so that their role is clear?
❑ Do all loops terminate?
❑ Do all array indexes stay within bounds?
❑ Do all method arguments match their parameters appropriately?
❑ Are modifications to parameters in methods consistent with how those param-
eters are passed?
❑ Do all overriding methods have the same signature as the parent’s method?
❑ Are all appropriate “clean-up” activities performed, such as files being closed?
❑ Is the implementation consistent with the design?