Checklist for an Efficient Code Review

Why Is Code Review Important?

Peer code review is a widely used technique by software engineering teams. The intuition is that if more software engineers review the code, there will be fewer bugs, and, in general, the maintainability of the code will be improved.

According to this study, such intuition is justified. The authors examine code review coverage on open source codebases and find that:

". . . poorly-reviewed code has a negative impact on software quality in large systems . . ."

In my experience, improving the code quality is just one benefit of a good code review process. A very important side-effect is that the knowledge about the codebase gets distributed among a larger group of people in the team. This makes a team more resilient (see Bus factor) and also helps the team to not lose the understanding of the system.

In summary, a good code review process should help software engineering teams with the following points:

1. Reduce the number of bugs.
2. Increase the maintainability of the code
3. Stimulate knowledge transfer and cross-training
4. Better code ownership distribution
5. Help the team not to lose cognitive control over the system
6. Good way for introducing new team members to the code base

A Simple Code Review Checklist

There are numerous code review checklists online and every software engineer has probably own ways of conducting a review.

Here, you can see a simple 8-steps checklist that I often use when performing code reviews:

1.  Do I Understand What the Change Is About? 

If the answer is no, I do not proceed further and ask the person sending the review for clarifications.

2.  Do I Understand What Is the Added Value of the Change?

If the answer is no, I do not proceed further and ask the person sending the review for clarifications.

3.  Was the Change Tested?

There should be at least some degree of empirical justification that the change works. If there is no such justification, I usually do not proceed further and ask the person sending the review for clarifications.

4.  Do I Recognize Any Logical Errors?

In my experience, logical errors are relatively rarely present; nevertheless, it is good to watch out for them.

5.  Is the Code Readable and Maintainable in General?

Code is written once and it might be read thousands of times. To be efficient in the long run, code readability is essential.

6.  Can I Spot Some Problems With Non-Functional Requirements?

Examples of this include scalability, performance, and security.

7.  Do I Want To Own This Code?

8.  Is It Compliant With the Code Style of the Codebase?

Consistency helps readability.

Conclusion

There is much more to be said about the code review process. For example, one interesting topic is what are best practices for creating code reviews: a greater number of smaller code reviews or fewer larger ones? Further, aggregated data derived from the code reviews could be even used as a metric for the speed of a software engineering team.

An efficient code review process plays a significant role in having an efficient software development process in general.