Software Code Review Template

Version: Draft
Table of Contents
Scope ........................................................................................................................................................................................ 2
Purpose .............................................................................................................................................................................. 2
Implementation ................................................................................................................................................................... 2
Source Code ........................................................................................................................................................................... 2
Security ................................................................................................................................................................................... 2
Instructions for Code Preparation ................................................................................................................................ 5
Code Review Checklist: Modules (P. 1 Of 1) ............................................................................................................ 7

Software Code Review Template 1

Scope
The main scope of the document.

Purpose
Specific reason (new feature, bug fix, etc.)

Implementation

Source Code

Security

Software Code Review Template 2

Stages: The overall code review process is divided into three stages.

Stage Name Purpose

Preparer ensures that code adheres to code review
checklist. Makes non-functional changes as necessary.
Notes any functional changes that should be made to
1 Code Preparation
adhere to checklist. Pays particular attention to
including all items required for header blocks and
adding helpful comments.
Individually or in small groups as desired, reviewers
review the code for all items on the code review
checklist, covering the areas of proper operation,
2 Off-line Code Review
adherence to coding guidelines, and implementation of
risk (and safety hazard) mitigation actions. Reviewers
recommend changes.
Participants review suggested changes from the off-line
code reviews, decide actions, approve code.
 The code review checklists filled out during off-
line review, and any recommended changes to code,
will be analyzed.
Formal Code Review  The code review record will be filled out to
3
Meeting document any actions, including required changes
to the code, and the approval of the code.
 The code review record and attached code review
checklists will be filed as the official record of the
code review.

Software Code Review Template 3

Definitions: The following definitions apply.

Code Review The formal review of software units or modules.

One function or routine, starting from its comment header block, to the last
a Unit
line of code or comment in the unit
The logical grouping of a set of units and its data structures. Normally a
a Module module will consist of one or more '.C' source files and it's associated '.H'
files.
the Presenter The person who authored the module or unit(s) for code review.
the
The two or more people who are reviewing the module or unit(s)
Reviewers
Software Requirements Specification – document containing the
SRS
user/system level requirements this piece of software must fulfill
Software Design Specification - document containing specific information
SDS
about the high level design of the Unit or Module being reviewed.

Software Code Review Template 4

Instructions for Code Preparation
STEP DESCRIPTION
The relevant module and any associated header files should be
Check out file to be formally 'checked out' of the version control or software code control
prepared system for any changes to take place.
The most recent checked-in or promoted revision should be used.
In order to prevent unintentional change of functionality, no changes
Make changes to each to the actual body of code or its structure should be made prior to a
unit/module: first pass review. Changes which do not affect the functionality (such
as the addition of comments) can be made.
See code review checklist in next section for standards each header
must follow. The general categories of information to be included are:
 Comments

Required:  Data usage (input/output parameters, data structures accessed,

changes to global variables, etc.)
Add code header
 Unit processing algorithm/design
 Potential failure modes related to system hazards to the patient;
required mitigation actions
 Miscellaneous notes on critical or risky areas of the design; design
assumptions; etc.
If, when preparing just one unit from a module, it is found necessary
Recommended:
to analyze other un-reviewed units, the addition of comments should
comment related
be made, and any helpful information that could be of future use in the
units
review and/or test of those additional units should be recorded.

Required: Document Recommended changes may be prepared on a copy of the module, and
recommended presented for review.
changes to actual Both the original and the copy with differences clearly indicated
code should be provided.

Software Code Review Template 5

 Lint must be run on the module or unit(s).
Each warning or message produced should be inspected and any real
issues corrected or flagged for correction
See the code review checklist on the following pages for a list of the
Run Lint
items Lint must be used to detect.
Global wrap-up' output can be discarded and ignored for code review.
The final Lint output will be recorded as part of the formal review
meeting.
The updated module(s) should be checked back into the official
Check in files
version control or software code control system
Prepare diagrams and Data flow, state diagrams or any other useful descriptive information
other supporting should be prepared to present along with the code for review. This
information information may be added to the SDS after the review.

Software Code Review Template 6

Code Review Checklist: Modules (P. 1 Of 1)
Use of this form:
Code Preparation: Use this checklist as a guideline for preparing the module
Off-line Code Review: The items on this checklist should be reviewed during Off-line Code
Review.
Formal Code Review This form, filled out during the Off-line Code Review, should be
Meeting: brought to the formal meeting, used as a checklist for verification of
all items, and attached to the code review record.

PRESENT?
CATEGORY ITEM
Y, N, N/A
Module header The module must have a module header block containing:

File name:
Original creator:
Date created:
Person who last changed code (if different from creator)
Code revision number and change history (with dates).
NOTE: The name of each changed unit should be listed
NOTE: If a change is made to correct a defect, the number or
ID of the defect corrected should be entered as well.
High level description: (explain the module's purpose, and the
name/purpose of key data structures, variables, sub-functions
used, etc.)
Failure modes and effects analysis: List types of failures
which could occur in this module and result in a hazard to the
patient. List the types of mitigation actions the software takes to
prevent hazards from occurring. If these risks are documented
in a separate document, reference it. (Editor’s note: for non-
medical projects, the corollary would simply be an appropriate
analysis of possible software failure modes, and what the
software should do in each case.)

Software Code Review Template 7

Module Grouping: Definitions and declarations should be separated
definitions and into distinct groups, each with a comment header.
declarations
For example, #defines, #includes, constant definitions, local
function prototypes, etc. would all be grouped separately.
If required for greater logical clarity, however, related
definitions and declarations may be mixed
Commenting: Each definition or declaration should have an
associated descriptive comment unless the declaration is really
obvious.

Software Code Review Template 8

CODE REVIEW CHECKLIST: Units (p. 1 of 2)
Use of this form:
Use this checklist as a guideline for preparing each unit in the
Code Preparation:
module
The items on the checklist should be reviewed during Off-line
Off-line Code Review:
Code Review.
This form, filled out during the Off-line Code Review, should be
Formal Code Review Meeting: brought to the formal meeting, used as a checklist for
verification of all items, and attached to the code review record.
PRESENT?
CATEGORY ITEM
Y, N, N/A
Function
Every function (Unit) must have a comment header block
header
containing:
block

Function name
Change history: List of each change to the unit, with the date of the
change and the name of the person making the change. Reference
defect numbers or ID if the change was to correct a defect.
Purpose: A short description of the unit's purpose. The description
should be written such that the unit's purpose in fulfilling the
original software requirements in the SRS can be understood.
I/O description: A description of the inputs and outputs expected,
specifying their acceptable ranges.
Return value: A description of the return value
External variables: A description of any external variables used,
specifying acceptable ranges.
Unit design/algorithm: A more detailed description of the unit's
processing. Should be detailed enough that reviewers can
determine whether the code meets its design, but not so detailed
that the description is just pseudo-code.
Failure modes analysis: A list of possible failure modes resulting
in hazards or error conditions, and any mitigation actions this unit
is required to take (for example, range checking a data value before
use.)

Software Code Review Template 9

 As noted in the Stage 1 Preparation instructions, Lint should have
been run on the module or unit(s). The final Lint output should be
recorded as part of the formal review meeting.
Each warning or message produced by Lint should have been
Lint results
inspected and any issues corrected. The items listed below must be
checked for.
'Global wrap-up' output can be discarded and ignored for code
review.
 Loop index not modified within the loop
 No extraneous code exists
 All data references defined, computed, or obtained from
external source.
 All defined and referenced calling sequence parameters agree.

Software Code Review Template 10

CODE REVIEW CHECKLIST: Units (p. 2 of 2)

PRESENT?
CATEGORY ITEM
Y, N, N/A
Code Checks
 Descriptive comments are accurate and informative.
 Return values (in particular error returns) are not ignored.
 Constants and literals are not hard coded.
 All variables used have obvious or descriptive names, and correct
scope.
 Local functions and non-automatic variables are declared static.
 System global functions have the module name as a prefix to the
unit name.
 All functions have prototypes (compiler checks this).
 Data structure fields are described and commented clearly.
 Code is logically correct (Code performs intended functions,
operates correctly)
 Numerical methods are sufficient
 Accuracy of control outputs to external devices are within
tolerance
 System I/O mechanisms are consistently used.
 Standard module communication techniques are used (e.g. use of
message system)
 Errors are detected and handled, and processing continued
 Error handling conventions are followed (standard use of error
handling task, etc.)
 Input values (or other data used) are checked for reasonableness
before use
 Where necessary, critical output parameters or data are checked
for reasonableness during processing
 Code pays attention to recovery from potential hardware faults
(e.g. arithmetic faults, power failure, clock).

Software Code Review Template 11

  Code pays attention to recovery from device errors.
 There is no redundant code.
 The structure is clean and indentations correct.
 Over complication is avoided.
SDS Check SDS (Software Design Specification) info for this unit is accurate

Software Code Review Template 12

FORMAL CODE REVIEW RECORD (page 1 of 2)
Fill in the following information as the formal record of the review:
Date and time of
review
Presenter
Reviewers
Module (or unit) under
review
Module (or unit)
revision number
reviewed.
Supporting __ SDS __ Diff listings for suggested changes __ New diagrams
information used in
review ___ Code Review checklists __ Lint output ___ Other ____________

Notes on recommended specifics of unit testing

Function name Specific notes on recommended unit testing

Additional hazards/ error conditions and failure modes identified.

Resulting hazard or error Mitigation action Does SW
Failure mode condition the user will software must need
see implement change?

Due Date -
Outstanding issues Assigned to
resolution

Software Code Review Template 13

SDS update
Y N Who:
required?

Sign-off date
NOTE: ATTACH CODE REVIEW CHECKLISTS (Module: 1 page. Each Unit: 2 pages)

Software Code Review Template 14

CODE REVIEW RECORD (page 2)
List of suggested and approved changes:
Change Description of implementation

Other code review comments

NOTE: ATTACH CODE REVIEW CHECKLISTS (Module: 1 page. Each Unit: 2 pages)

Software Code Review Template 15