Code Review

Introduction

A code review is a formal review that is organized to ensure the source code complies to programming guidelines and matches its intended design. It is imported that the design related to the source code is clear to every reviewer that participates in the code review. Useally, a code review is organized for each declaration and definition file (i.e. .h and .c files). The various review methods are documented in the Software Quality Plan. In general there are two versions of the code review.

1. A Technical review including kick-off, inspection and logging meeting. This variant is organized for critical parts of the software.
2. A Peer review which excludes an inspection meeting and a joined logging meeting. This variant is organized for non-critical software parts.

code reviewA formal inspection method in which the source code of the software is inspected. This review is normally conducted for peer developers

Input criteria

Before the code is review, the code has been approved by the static analysis tool 15 Code review&Before the code is review, the code has been approved by the static analysis tool&\ \hline

. Warnings from the static are either solved or suppressed 15 Code review&Warnings from the static are either solved or suppressed&\ \hline

. See chapter 8.

Motivation

A code review is a static analysis that is executed by hand. It is a very effective method intended to ensure that the source code really implements the design. Also, mismatches with the committed programming guidelines can be found. A code review must have been organized before designing any of the dynamic tests. A code review must at least involve two reviewers that did not write any significant part of the code.

Process flow

Figure 3.1: Flow chart for a code review

Technical review

At first, a kick off meeting is organized. During the kick-off meeting, the design model that is implemented by the code, is explained by the author of the code. Also an estimate of the required time to inspect the source code is given by the author. A kick-off meeting is important because it helps to carry out the inspection efficiently and it may reveal design problems as interpreted by the author.

Hereafterthe inspection meeting is organized. This is a meeting in which the reviewers inspect the source code individually and document their findings using the Software Quality Report (SQR). It is important that the description of a problem is written as a clear one-liner. With the technical review, it is allowed that every reviewer inspects a different part of the source code.

When the inspection meeting has finished and the findings have been documented, a logging meeting is organized. The logging meeting is organized as a Fagan inspection. This means that this is a formal meeting with the intend of finding more defects than already documented. During the logging meeting, each reviewer will issue his findings. The logging meeting includes an independent moderator to ensure the meeting is conducted efficiently (avoiding endless discussions etc.). Discussions may only be allowed to clarify the findings, not to defend certain choices or to discuss possible solutions.

After the logging meeting, the coverage level to use for designing test cases is discussed. In general, this will be 100% statement coverage for normal software and 100% branch coverage for safety-involved sofware. for a more detail explanation about code coverage see section 4.5. The author will document the minimal coverage level in the source code (see chapter 11) for an example.

Peer code review

The peer code review is a code review without a final logging meeting.

Each reviewer inspects the same part of the software individually. This inspection does not have to be scheduled for each reviewer at the same time. The code review starts with the same kick-off like the technical review. After the kick-off each reviewer will schedule and conduct the inspection and documents his findings in an SQR. After the inspection, the results are mailed to the author who will collect and process the findings.

Exit criteria

The findings of the code review have been collected and processed. 15 Code review&The findings of the code review have been collected and processed.&\ \hline

This means that the author has documented whether a certain issue has been solved, ignored or planned in future. All suppressions in the code have been evaluated. 15 Code review&All suppressions in the code have been evaluated.&\ \hline