7 ways to improve your code reviews

A code review is a process where some developers analyze a teammate’s code, identify potential errors and suggest improvements. How can we improve this daily task by spending the same amount of time on it?

Illustration of code review (generated by Microsoft Bing AI)

All code is guilty until proven innocent — Anonymous

Why doing Code Reviews?

First, why bother taking time reviewing someone else code?

The code review process has several benefits:
- Ensure code quality: it is for me one of the most valuable benefit of a code review
- Improve security: someone can spot a security issue that could cost a lot of money otherwise
- Reduce development cost: it seems contradictory, however it’s during this time that most of the defect are spoted.
According to a 2009 study, (Embedded Software: Facts, Figures, and Future.) 50% of defects are spotted during code reviews wheras 30% during tests. It can even scale up to 65% using a collaborative review methodology.
- Share knowledge with the team: code reviews are a good way for team members to learn more about the code base and good practices

7 Tips

1. Be sure of yourself when asking for review

As a developer you must ensure to check the following things before asking a peer to review your code:
- The code is compiling (this can seem obvious but I’ve seen a lot of PR that don’t)
- All Unit Tests pass
- Double check your spelling (it will avoid some poor feedback from your peers)
- Clean up remaining useless comments or TODO
- Add a clear PR description

2. Focus on standards

Within a checklist of good practices set with the team, focus on reading the code to see if the following standards are matched :
- Coding standards: use a checklist. The checklist should be validated by the dev team, and sometimes by the company
- Security standards: check whether the code has vulnerabilities or not, here again, a specific checklist can be usefull
- Performance standards: check if the new code will have a negative impact on the application and if it’s acceptable or not
- Testability standards: does the code include Unit Tests?
- Documentation standards: is the code worth outside documentation?

A specific article can be done to speak about all these standards.

3. Embrase a positive code review culture

Code reviews can be painful for the author if we don’t have a positive review culture.

Here are some key points you can work on with your team peers:
- Focus on aspects that brings most value
- Criticize the code and not the author, everyone is doing mistakes, aim is to continualy learn and progress through code reviews
- Invite junior and newcommer to join code reviews as reviewer, they will improve their skills, learn more about the code base, and they can have new or fresh ideas older team members won’t
- There are no stupid questions! As a reviewer, feel confident to ask a simple question, the author will just answer it simply. It will avoid situations like the following famous picture

There are no stupid questions: image by Manu Cornet under Creative Commons license

4. Make the review short

Several studies have well proven that focus diminishes over time.
In short, don’t review more than 400 lines of code at a time, and spend less than 60 minutes to review PRs in a row.

Defect Density over Lines of Codes reviewed — source: smartbear

Defects found over time (study from Cisco Systems in May 2006, source: josipmisklo)

5. Use automatic tools to save time

Some tools like SonarQube can spot code smells, potential bugs or bad practices automatically. Let it do the work for you and focus instead or other things that the tool doesn’t.

6. Set goals and capture metrics

I’m not personnaly a big fan of this piece of advice. However, it can help some teams measuring their progress.

Here are some metrics you can use:
- Inspiration rate: the speed with which a review is performed
- Defect rate: the number of bugs found per hour of review
- Defect density: the average number of bugs found per line of code

7. Change the code review methodology

You might have noticed all previous tips are given in a context of peer code review. There are 2 other ways you can do a code review. Let’s have a quick look on them:
- Collective review: the dev team oraganizes a code reviewing session
- Peer programming: one is typing while the other dev is reviewing

Here is a simple table with advantages and drawbacks of each method:

Comparative table with code review methods

It’s easier to do a peer review than synchronize with all the team members to do a review session. However, it will help everyone in the team feels like the owner of the code base. If you hear too much of “your code” in your team instead of “the code” or “our code” it can be a way to solve it.
Collective review is obviously the best way to achieve efficiency (number of detected defects) as all the team is reading the code at the same time.

Meanwhile, peer programming is the best option to have quick feedback. It can be a good compromise as it is easier to set up than collective review.

In short, code reviews can be improved either by better process, or by being more pragmatic and of course with a desire of improvement.

If you have other tips you use in your team to improve code reviews, feel free to add it in the comments.