A testing technique where source code logic and structure are traced manually in a meeting of interested technical parties to analyze the programmer's logic and assumptions.

Definition

A Code Review is a meeting where software code is presented to project members, peers, DBAs or other interested technical parties for comment and approval. A Code Review is a manual testing technique where source code logic and structure are traced manually by the group to analyze the programmer's logic and assumptions.

Code Review provides the opportunity to evaluate programming work prior to production release in order to :

• Find errors
• Improve the software product
• Consider alternate implementations
• Evaluate conformance to standards and specifications
• Enhance maintainability of code
• Educate an audience regarding the software product

When to do a Code Review

During the Development Cycle, code reviews should be done whenever a discrete module has been coded, unit tested and documented. Several iterations may be necessary before the module is approved by reviewers.

Code reviews should be done whenever an enhancement or maintenance work has been completed, prior to release to production.

Whether or not code should be checked in depends on the programming environment, the build schedule, and the type of change. Breaking a build is not acceptable.

Examples and Ideas

How to set up a code review?

The code review can be as formal or informal as the code base dictates. If the code changes are relatively small, the code review may be done between two programmers in front of a terminal. When reviewing a sizable or complicated code base, the code review is best conducted in a conference room with a large monitor so participants are all viewing the same code. In this case, it may be necessary to schedule more than one session.

If a monitor is not available, code printouts are acceptable for small groups. In either case, the old code and changed code may be presented side by side so differences can readily be seen.

Keep the code review session to one hour.

Assign someone the job of Notetaker. This could be the programmer or a reviewer.

If reviewers are not familiar with the program function, provide a diagram to define the context.

What is the programmer's responsibility?

• Ensure that requirements have been met, that comments are complete, and that code has been thoroughly unit tested.
• Make it easy for reviewers to see the code changes. Provide a listing with new code highlighted, a delta listing, or display using online diff tools.
• Lead the meeting in an organized fashion. Plan the starting point and follow the flow of logic. Prepare input and output samples where appropriate.
• Anticipate questions and issues that could be raised by reviewers.
• Set aside ownership issues.

What is the reviewer's responsibility?

Prior to the meeting, review and be clear about the requirements. During the code review, ask questions and raise issues in a supportive manner.

• Are software standards being followed?
• Is the coding style consistent with the existing source file? With the rest of the product?
• Were the requirements understood by the programmer?
• Were the requirements complete? Are there unanticipated side effects elsewhere in the application?
• Were the changes correct, both logically and functionally?
• Are coding comments complete?
• Are there any installation issues? If so, are they documented?
• Have security needs been addressed?
• Respect the judgment of the developer when it comes to minutiae.

Tools and Reviews

Visual Source Safe (VSS), WinDiff, SURE, Delta Printouts.

Local Resources

The best resource is the project team. However, occasionally a small project is staffed by only one person or a new technology is used where supporting knowledge is scarce. For Mainframe projects, the MDC is the primary resource. For Windows and Web-based products, see the DAWGfor support.

Expected Costs

The major cost of a Code Review is time. Avoid these mistakes to help insure a pleasant and beneficial experience.

Information Overload - A code review covering too much may end up overwhelming attendees. Tangential discussions should be steered outside of the code review.

Lack of Programming Standards - There must be consistency. If code is accepted by one reviewer but rejected by another, or accepted on one occasion but rejected on another, developers will become confused and frustrated. If standards are published, developers can ensure compliance, allowing a much more positive and less time-consuming review process. Reviewers can direct more attention to unusual and complex coding techniques.

Developer Reluctance - At worst, a code review can become an unnerving experience for a developer if constructive criticism becomes destructive criticism. The process must be considered by all parties an opportunity to train the developer, enlighten the rest of the project team, and maintain or improve the quality and performance of the application. Make it a win-win situation.

Conflict Resolution - Genuine conflicts, where both sides have a legitimate argument, can obstruct the success of a project if not handled. The Project Manager or other administrator may need to resolve such differences.

Expected Benefits

The overall benefits are to improve the performance and quality of applications and knowledge of developers.

The quality of software deliveries is improved by finding bugs not detected by the developer, enforcement of coding standards, removal of questionable coding practices, ensuring documentation is clearly written and complete, and disseminating information about software changes by having other team members look at the work.

Improved developer performance is ensured by the mentoring of the developer by peers, the discussion of coding style and technique, and evolution of programming standards.

The project team benefits from additional cross-training.