Code Review Best Practices

Improve code quality and help developers grow professionally with a well-thought-out code review process.

Here are code review best practices to maximise the value of a fresh perspective by identifying poor design patterns and bugs, ensuring that every new feature or product is created using high-quality code.

1. Create a code review checklist

Readability: Are there any redundant comments in the code?
Security: Does the code expose the system to a cyber attack?
Test coverage: Is there a need to test more cases?
Architecture: Does the code use encapsulation and modularisation to achieve separation of concerns?
Re-usability: Does the code use reusable components, functions, and services?

2. Set goals and capture metrics

Before implementing a process, your team should decide how you will measure the effectiveness of peer review and name a few tangible goals.

Using SMART criteria, start with external metrics. For example, “reduce support calls by 15%,” or “cut the percentage of defects injected by development in half.” This information should give you a quantifiable picture of how your code is improving. “Fix more bugs” is not an effective goal.

It´s also useful to watch internal process metrics, including:

Inspection 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

3. Do not review for more than 60 minutes at a time

Just as you shouldn´t review code too quickly, you also should not review for too long in one sitting. When people engage in any activity requiring concentrated effort over a period of time, performance starts dropping off after about 60 minutes. Studies show that taking breaks from a task over a period of time can greatly improve quality of work. Conducting more frequent reviews should reduce the need to ever have to conduct a review of this length.

How you manage your review time may depend on your situation, but some general guidance is:

Limit your review to 200–400 lines of code at once
Don’t spend more than one hour at a time reviewing code
Plan for 3 seconds of review time per line of code

4. Automate to Save Time

There are some things that reviewers will need to check in manual reviews. But there are some things that can be checked automatically using the right tools.

Static code analysers, for instance, find potential issues in code by checking it against coding rules. Running static analysers over the code minimises the number of issues that reach the peer review phase. Using tools for lightweight reviews can help, too.

By using automated tools, you can save time in peer review process. This frees up reviewers to focus on the issues that tools can’t find — like usability.

5. Provide constructive feedback

The type of feedback you provide is crucial in building rapport with your team. You should make the effort to ensure that your feedback is helpful and comes from a well-intention place.

Constructive feedback will help a code author get closer to merging their source code. This doesn’t mean you should be solving or fixing their code for them. But your feedback should point them in the right direction, rather than toward a void of confusion.

An example of how not to give feedback: “This code is wrong. Why did you do this?”

Always explain the “why” behind your feedback. If you suggest an alternative line of code, you’d be depriving the code author from a learning opportunity if you didn’t explain why it might improve their original code. Explaining the “why” also reduces the need for follow-ups, by giving the author the necessary context to incorporate your feedback.

6. Focusing on coding standards, not personal preference

There are times where perfectionism is the enemy of good code. Sometimes you’ll need to sacrifice perfectionism in order to be a team player. Your focus when reviewing code changes should be that they follow your company’s coding standards and general coding best practices.

Unless it affects the functionality of the code or opposes your company’s code style guide, you’ll want to refrain from getting too nitpicky about trivial concerns (such as declaring variables in a certain order). If nitpicky changes are what you find yourself tripping up on, perhaps your team really has a need for more coding standards or automated tools (such as code style enforcement in your CI).

Benefits of code reviews are numerous, some of which include:

• Teaching and mentorship opportunities for new developers
• Debugging
• Improving code maintainability
• Encouraging authors’ ownership over their code