What is a code review?

A code review (sometimes called a program inspection) is a formal process where a software developer presents the code he or she has written to other software engineers who are familiar with the project. The code is scrutinized carefully to identify potential bugs, design problems, non-compliance with project standards, inconsistencies, and any other problems in the code.

Why use code reviews?

• Studies have shown that code reviews are a very cost-effective way of improving software quality.
• Code reviews will often disclose problems that, if not corrected early, would lead to delays during code integration and final testing.
• Code reviews also provide mentoring, enabling junior members of the programming staff to learn the practices of the experienced team members.
• Coding standards of an organization are applied and enforced through code reviews.
  Code reviews will generally add a few days to the code development process, because it takes time to prepare and present a code review. If significant defects are found during a code review, the code development time will need to be increased to allow for correcting these defects. However it is much more cost-effective to make those corrections early in the development process, rather than waiting until the defects have been disclosed during system testing.

  Are code reviews always necessary?

  Any project with more than one code developer will benefit from code reviews. In some cases a code review should always be required:

• If a lot of new code is being written.
• If some of the developers are new to the project.
• If some of the developers are inexperienced.
• If the project involves the development of many different interacting modules.

  There are significant hurdles to requiring code reviews in a project, such as:

• Few programmers like to have others look for defects in their work. It can be embarrassing, especially for programmers who are new to a project. Programmers will often avoid or postpone code reviews if they are not explicitly required.
• Code reviews come at a time near the completion of code-writing, when there is often considerable pressure to complete the development. Management may be reluctant to spend the time for code reviews if they would appear to lengthen the schedule.
  These hurdles (e.g., new programmers and pressure to complete) are, however, strong indicators of the need for code review.
  If the code being developed involves the reuse of existing software, it may not be necessary to review the code in detail. In some software development processes there may be other processes that replace or avoid code reviews. For example, in Extreme Programming (http://www.extremeprogramming.org), pair-programming can achieve the same objectives as code reviews. If code reviews are omitted from a project, there should be a clearly stated reason why they are not necessary.

  How to conduct a code review.

• First, it is important to have a team environment that is conducive to having good code reviews. Management must require code reviews by all developers, and allow for adequate time in the schedule. Coding standards and standards for conducting code reviews should be available and accepted by all team members. It must be understood that a code review must provide constructive criticism, in a way that will improve the software of the project. The code review is never to be used as a means of evaluating the developer.
• A small number of developers (say 3 to 5) should be invited to the code review. They should be developers whose own work is close to the code being reviewed, and who are familiar with the requirements of the code. The code to be reviewed should be small enough to be examined closely in a one-to-two hour meeting.
• The code developer should distribute copies of the code several days in advance to the attendees, with a complete statement of the requirements. This code should be up to date and syntactically correct. Printed copies of the code should include line numbers for reference. The attendees should examine the code in advance of the meeting, prepared to formulate any questions and concerns to discuss at the review.
• During the code review, the author of the code should provide an overview, stating the purpose or requirements of the code and describing how it operates. It is very valuable to provide high-level UML diagrams, showing how the code fits in the overall design, as well as lower-level UML diagrams showing the interaction of the various components of the code being reviewed.
• The code reviewers should look in detail at the code to ensure it meets project standards and to identify potential bugs. They should provide specific constructive criticism for improving the code, such as changes to interfaces or data structures. General criticisms should be avoided. The author of the code should listen openly to all concerns that are raised and be prepared to discuss the code in detail, especially parts that are particularly complex or where the interaction with other modules is critical to the correct operation of the code.
• At the completion of the meeting there should be a list of action items; that is, a list of code and/or design changes that are required. Code reviewers should be available for follow-up discussions with the code author, to clarify the issues they raised during the meeting. If the recommended changes are extensive, an additional code review should be scheduled, after the changes have been implemented.

  Where to get more information on code reviews.

• An excellent discussion of code reviews is in Wikipedia (e.g. see http://en.wikipedia.org/wiki/Code_review). Wikipedia includes several links, including tools that are helpful in code reviewing.
• A good textbook is I. Sommerville, Software Engineering. Note that Sommerville refers to code reviews as program inspections .