CS-489 Code Review Procedure

Dr. Mark J. Sebern

Version 1.1 (10/13/1998)

The code review is an important part of software engineering practice. For the purposes of this course, the following guidelines are suggested.

Review roles

• Moderator (team quality/test manager)
  • Assigns review roles
  • Runs the review meeting.
  • Keeps team on task.
  • Ensures adherence to review process.
• Secretary/scribe
  • Records all defects, comments, correction ideas, notes.
  • Prepares formal code review report.
  • At conclusion, records team consensus as to code status:
    • Acceptable as presented.
    • Acceptable if noted defects are fixed.
    • Not acceptable in present form; a follow-up review will be scheduled.
• Presenter
  • Normally the author of the code under review.
  • Leads other team members through code in a logical fashion
  • Answers questions regarding implementation (and corresponding analysis/design).
• Reviewer(s)
  • Should have read over code before the review meeting and have prepared questions and notes.
  • Raise issues and possibly suggest solutions.

Review process

• When a defect is found
  • Secretary records details of defect.
  • Team members may suggest a correction.
  • Discussion should be kept as short as possible; details of correction can be worked out later.
  • Note phase (planning, design, coding) where defect was most likely injected.
• Ground rules
  • Goal is to work together to produce a better product.
  • No personal attacks allowed.
  • No prolonged argument about possible corrections.
  • Concentrate on proper implementation of design; don't get hung up on spelling/grammar/formatting.
• Other notes
  • If discussion becomes "I thought we were supposed to do X", a design review or even an analysis review may be needed.
  • It may be desirable to review low-level functions or low-coupling objects first, before moving to higher-level function or objects.
  • Normally limit review meetings to an hour (or two, at most).

Review report

The code review report should contain the following elements:

• Meeting time and date.
• Review roles and members assigned to each.
• Copy of code reviewed (if requested by team leader or "management").
• List of defects and issues.
• Code status as determined by review panel.
• Comments on the review process and how it might be improved.

This page was last updated on October 13, 1998; send comments to Mark Sebern.

Copyright information