Code Review

Bread Crumbs: Home - SW_Dev_Proc - Impl - Code Rev

All source code should be peer reviewed according to a checklist. This includes unit test source code as well (test harness code, test driver code, stub code, etc.). PSP (Personal Software Process) metrics should be recorded to provide data for analysis so that process improvements can be made.

On this page, the following topics will be covered:

Review Checklist

Notes:  RD## means Review Defect ##. 
        All text in green italics is example text meant to be used as guidance.

Source File:        abc.cpp
Date Stamp of File: 4/26/2007

Rule

Defect

ID

Problem Description (optional)

Line Of Code

Fix Time (min)

SR01

RD01

 

213

 

 

RD02

 

310

 

SR02

 

 

 

 

SR03

RD03

 

125

 

 

RD04

 

316

 

 

RD05

 

333

 

SR04

 

 

 

 

SR05

RD06

Missing pre-conditions and post-conditions sections.

200

 

 

RD07

 

451

 

SR06

 

 

 

 

SR07

RD08

Beginning of function name is an acronym with all caps.

111

 

SR08

 

 

 

 

SR09

 

 

 

 

SR10

RD09

 

263

 

 

RD10

 

289

 

SR11

 

 

 

 

SR12

 

 

 

 

SR13

RD11

 

295

 

CR01

RD12

Multiple inheritance with “diamond of death”.

23

 

CR02

RD13

 

345

 

 

RD14

 

373

 

CR03

 

 

 

 

CR04

RD15

Search function uses tail-recursion.

319

 

CR05

RD16

 

127

 

 

RD17

 

134

 

 

RD18

 

337

 

CR06

 

 

 

 

CR07

RD19

General exception is thrown when an error status code is returned from the function call; however, the error status information is not included in the exception that is thrown and is therefore lost.

351

 

CR08

RD20

 

219

 

CR09

 

 

 

 

CR10

 

 

 

 

CR11

RD21

Search function has multiple return statements.

319

 

CR12

RD22

 

330

 

CR13

 

 

 

 

PSP Metrics

Project planning requires the estimation of resources that will be needed to complete the project. Having longitudinal metrics data across several project can be invaluable with regards to accurately estimating the resources that will be needed for a project. By tracking defects found during code reviews, metrics such as the total number of defects injected during the code review activity and how long it took to fix those defects can be tracked over time. This data can be entered into a project metrics spreadsheet or even a database. Since it takes time to fix defects, this activity must be accounted for when estimating resources needed (time is a resource). One can estimate the number of review defects expected and then by recording the actual defects found during code review, the estimate can be compared to the actual figure. This can help to produce better estimates in the future.


No part of this work should be produced or used without the permission of the authors: Michael Turner and Dr. Sharon A White.