Code review is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the persons must not be the code's author. The persons performing the checking, excluding the author, are called "reviewers". Although direct discovery of quality problems is often the main goal, code reviews are usually performed to reach a combination of goals :
Finding defects improve quality regarding external aspects, especially correctness, but also find performance problems, security vulnerabilities, injected malware,...
Learning/Knowledge transfer help in transferring knowledge about the codebase, solution approaches, expectations regarding quality, etc; both to the reviewers as well as to the author
Increase sense of mutual responsibility increase a sense of collective code ownership and solidarity
Finding better solutions generate ideas for new and better solutions and ideas that transcend the specific code at hand.
Complying to QA guidelines Code reviews are mandatory in some contexts, e.g., air traffic software
The above-mentioned definition of code review delimits it against neighboring but separate software quality assurance techniques: In static code analysis the main checking is performed by an automated program, in self checks only the author checks the code, in testing the execution of the code is an integral part, and pair programming is performed continuously during implementation and not as a separate step.
Types of review processes
There are many variations of code review processes, some of which will be detailed below.
Formal inspection
The historically first code review process that was studied and described in detail was called "Inspection" by its inventor Michael Fagan. This Fagan inspection is a formal process which involves a careful and detailed execution with multiple participants and multiple phases. Formal code reviews are the traditional method of review, in which software developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review. An important byproduct of a properly conducted formal code review is a written record describing:
Who: Names of those involved in the Review.
When: Date and time the Review was conducted.
Why: Best-Practice, Error Detection, Vulnerability Exposure, Malware Discovery or a combination.
What: Name of the class, method, or program, plus line ranges and other particulars specific to the reviewed code.
Result: What was disclosed during the course of the Review.
Regular change-based code review
In recent years, many teams in industry have introduced a more lightweight type of code review. Its main characteristic is that the scope of each review is based on the changes to the codebase performed in a ticket, user story, commit, or some other unit of work. Furthermore, there are rules or conventions that embed the review task into the development process, instead of explicitly planning each review. Such a review process is called "regular, change-based code review". There are many variations of this basic process. A survey among 240 development teams from 2017 found that 90% of the teams use a review process that is based on changes, and 60% use regular, change-based code review. To perform change-based reviews smoothly, authors and reviewers use software tools: informal ones such as pastebins and IRC, or specialized tools designed for peer code review such as Gerrit and GitHub's pull requests. Change-based review is also referred to by other names, like "tool-assisted code review", "modern code review", "contemporary code review" or "differential code review". Many of these terms lack a definition that is precise enough to specify whether they are equal to or only similar to "regular, change-based code review".
Other types
In addition to the above-mentioned code review types, there are many more terms used to refer to certain variations of the process. Examples are:
Over-the-shoulder one developer looks over the author's shoulder as the latter walks through the code.
Email pass-around source code management system emails code to reviewers automatically after checkin is made.
Walkthroughs, usually with an emphasis on the presentation and discussion of the code in a meeting.
Pair programming, i.e., two authors that develop code together at the same workstation, is very similar to code review but not a code review in the narrow sense. The "IEEE Standard for Software Reviews and Audits" describes several variants of software reviews that can also be applied to code.
Efficiency and effectiveness of reviews
Code reviews require a considerable investment of effort from the software developers. Especially formal inspection has been criticized for this. The needed effort has to be outweighed by an adequate number of detected defects. Capers Jones' ongoing analysis of over 12,000 software development projects showed that the latent defect discovery rate of formal inspection is in the 60-65% range. For informal inspection, the figure is less than 50%. The latent defect discovery rate for most forms of testing is about 30%. A code review case study published in the book Best Kept Secrets of Peer Code Review found that lightweight reviews can uncover as many bugs as formal reviews, but were faster and more cost-effective in contradiction to the study done by Capers Jones The types of defects detected in code reviews have also been studied. Empirical studies provided evidence that up to 75% of code review defects affect software evolvability/maintainability rather than functionality, making code reviews an excellent tool for software companies with long product or system life cycles. Although most found issues are maintainability problems, high impact defects can be found, too. A special category of defects that often has a high impact are security vulnerabilities such as format string exploits, race conditions, memory leaks and buffer overflows, thereby improving software security.
Guidelines
The effectiveness of code review was found to depend on the speed of reviewing. Code review rates should be between 200 and 400 lines of code per hour. Inspecting and reviewing more than a few hundred lines of code per hour for critical software may be too fast to find errors. Some sources recommend to use a checklist of the most important problems for reviewing code. For example, a STIG provides an excellent vulnerability checklist.
Supporting tools
Many teams perform change-based code reviews based on general-purpose development tools: Online software repositories such as Subversion, Mercurial, or Git and ticket systems such as Redmine or Trac allow groups of individuals to collaboratively review code. But there are also special purpose tools for collaborative code review that can facilitate the code review process. Static code analysis software lessens the task of reviewing large chunks of code on the developer by systematically checking source code for known vulnerabilities and defect types. A 2012 study by VDC Research reports that 17.6% of the embedded software engineers surveyed currently use automated tools to support peer code review and 23.7% expect to use them within 2 years. Tools that work in the IDE are especially useful as they provide direct feedback to developers.
