Why Review Code?

Authors need editors to catch mistakes. It is human nature that one cannot adequately proof-read one's own work. Authors of software need the same assistance as authors of novels to achieve the goals of the software organization. Year after year, we hear from developers that code review is the #1 way to improve their code quality.

The Benefits of Code Review

The purpose for code reviews are as diverse as the environments in which they are conducted. However, almost all code reviews have these goals in common:

• Defect-free, well-documented software.
• Software that complies with enterprise coding standards.
• Teaching and sharing knowledge between developers.

Other objectives often include: maintainability, security, consistent end-user documentation, adequate comments in code, complete unit tests, and scalability.

In our 2021 State of Code Review report, we asked 1100 developers:

What are the main benefits of code review?

You can read the full report here. Compared to prior reports, the 2020 report shows an overall increase in recognized benefits across the board. For some teams, peer reviews are a way to onboard and train new members. For others, peer reviews are a compliance-critical component of software assurance.

How code review works

A code review involves one or more developers examining source code they didn't write and providing feedback to the authors, both negative and positive. Ideally the reviewers are completely disengaged from the project they are reviewing as this maximizes objectivity and ensures the code is readable and maintainable even by those not already well-versed in that project. Typically the reviewers will have a standard checklist as a guide for finding common mistakes and to validate the code against the company's coding standards.

Code review takes place during all stages of development, except with small projects such as demos and experiments that are designed to be written quickly and probably thrown away. Even during the final stages of development when everyone is trying to meet a deadline, code reviews greatly reduces the number of regression bugs and ensure that company coding practices are not abandoned. Using best practices of code review, the process can greatly mitigate the costlier QA defects that are found right before launch.

Our code review software saves time in almost every aspect of the code review process.

Code Review is the single greatest way of noticing and killing bugs, increasing overall understanding, fixing design problems, and learning from one another.

— Graydon Hoare

Finding bugs on the cheap

It is well-documented that the earlier a bug is found the cheaper it is to fix. Fixing a bug in QA is more than twice as expensive as finding it in development. Just as we have trouble seeing "obvious" mistakes in our writing, developers frequently make simple errors that are easily and quickly caught by external review. We have developed a code review ROI calculator to easily show the savings in time and payroll for bug fixes. In fact, a NASA study found that code review detected almost twice as many defects per hour as testing.

A code reviewer will look for common bugs, especially those that are notoriously difficult to find after-the-fact. These include proper thread synchronization, dealing with error conditions correctly and completely, correct accounting for reference-counting and other potential resource leaks, security problems, and ensuring that unit tests cover all code paths, error cases, and limit cases.

Inspection of a 20,000 line program at IBM saved more than 85% of programmer effort by detecting major defects through code review instead of testing.

— IEEE Trans. on Software Engineering, SE-12(7):744-751, July 1986.

Ensuring maintainability

The expense of developing software is not just in its initial creation but in the ability of developers to use and modify existing code in the future. Software is notoriously difficult and expensive to maintain. This is especially true when a developer leaves a project and a new developer arrives, but it is even true with a single developer looking back on code he wrote six months ago.

Maintainability is generally achieved by code organization and adequate comments. A person uninvolved in the project should be able to read a portion of code and understand what it does, see the constraints and preconditions of its use and contextual information (e.g. the author used a peculiar technique because of a bug in the OS). In addition, software organizations often have coding guidelines ranging from whitespace conventions to the maximum size of a function. A reviewer can provide the ignorance and objectivity necessary to ensure these goals.

Shell Research saved an average of 30 hours of maintenance work for every hour invested in inspections.

— Software Practice and Experience, 22(2):173-182, Feb. 1992.

Learning and sharing

Every project has a host of unwritten rules and tacit understandings. This "institutional knowledge" must be transmitted to all new arrivals on a project. By definition it is impossible (and perhaps not even cost effective) to write down this information or to convey it all in one sitting. The inductee must acquire this information in the first months on the project, usually elicited from experienced developers when he does something wrong.

Code review can facilitate the communication of institutional knowledge as it relates to code written by the newbie. Experienced team members have the opportunity to impart their wisdom and advice.

Software to facilitate code review

Code review can be expensive to implement if the participants don't have the right review tools. Dedicated peer code review tools like Collaborator save time in almost every aspect of the code review process.

With a review tool, your team can:

• Create templates and checklists for certain types of reviews
• Conduct remote, real-time reviews at each member's convenience
• Capture metrics automatically on your review process and defects 

In this video, we quickly walkthrough some of these features in Collaborator.