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 less bugs and in general the maintainability of the code will be improved.

According to this study, this 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 code base gets distributed among larger group of people in the team. This makes a team more resilient (see Bus factor) and also helps the team to not loose the understanding of the system.

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

1. Reduce 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 loose the 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 for conducting a review.

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

1. Do I understand what the change is about? – if 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 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 an empirical justification that the change works. If there is none, I usually do not proceed further and ask the person sending the review for clarifications.
4. Do I recognise any logical errors? – in my experience those are relatively rarely present, nevertheless good to watch out for.
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 e.g. scalability, performance, security?
7. Do I want to own this code?
8. Is it compliant with the code style of the code base? – 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 the code reviews – more 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.

References:

If you have any questions about the article or want to discuss the topic, do not hesitate to contact us at .

— — —

We put a lot of effort in the content creation in our blog. Multiple information sources are used, we do our own analysis and always double check what we have written down. However, it is still possible that factual or other mistakes occur. If you choose to use what is written on our blog in your own business or personal activities, you do so at your own risk. Be aware that Perelik Soft Ltd. is not liable for any direct or indirect damages you may suffer regarding the use of the content of our blog.