How should a code review be done?

Home/Blog/6 code review best practices for a happier codebase and team

May 06, 2022 - 6 min read

Erica Vartanian

Code reviews are crucial to nurturing quality code. And just as there’s such a thing as bad code, there’s also such a thing as bad code reviews.

So how do you perform code reviews such that they better your team’s codebase, productivity, and overall happiness?

Today, we’ll talk about 6 code review best practices to consider when reviewing someone else’s code. As you learn how to better support your team members through code reviews, you’ll also learn transferable skills that can help you advance to a future role in leadership.

We’ll cover:

• 6 code review best practices
• Benefits of code reviews (and why we love them)
• Wrapping up and next steps

Learn how to support a developer team.

Try one of our 300+ courses and learning paths: Become an Effective Software Engineering Manager.

6 code review best practices for a happier codebase and team

1. Don’t rush your review

You can’t do an effective code review if you’re rushing through too many lines of code. Quality is certainly more important than quantity when you’re reviewing lines of code. If you spend too much time reviewing code in one sitting, your review will become less effective and less attentive (which defeats the purpose of getting a fresh pair of eyes during code review).

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

2. 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-intentioned 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.

3. Use a code review checklist

Even if you think you can cover all the bases, checklists can help streamline your code review and focus your priorities on what matters most. You could have a personal code review checklist, but ideally, you’ll have a code review checklist that’s followed consistently across the development team.

A code review checklist might contain the following considerations for the new code:

• Readability: Is it clear what the code is doing? Does the code have meaningful naming conventions and code comments?
• Performance: Does the code take too long to run? Is there a simpler solution that would be worth implementing?
• Reusability: Does the code follow best practices such as the DRY principle?
• Test coverage: Are there any edge cases that are unaccounted for?
• Maintainability: Does the code follow best practices such as loose coupling and high cohesion?

4. Use code review tools

Code reviews would be unnecessarily tedious without code review tools.

Some popular code review tools are GitHub, GitLab, BitBucket, and Gerrit – but there are many others as well. Each tool has different features, but ultimately, they can all serve to streamline code reviews and easily integrate them into your team’s software development workflow.

Learn how to support a developer team.

Try one of our 300+ courses and learning paths: Become an Effective Software Engineering Manager.

5. 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).

6. Ask open-ended questions

Instead of providing explicit suggestions for improvements, it’s helpful to ask open-ended questions on a piece of code. Open-ended questions invite the author to think critically and independently about their code. This can set the stage for discussion, knowledge sharing, and mentorship.

You might learn something new by asking open-ended questions, rather than assuming you know the context behind the author’s code. Some developers think that code reviews are only a learning for junior developers – but even the most seasoned developers can learn from a beginner in the field.

Benefits of code reviews (and why we love them)

Peer code reviews are an essential part of the software development process to help keep our code quality in check. We don’t realistically have time to write perfect code when we’re aiming to ship new features. Even if we did, nobody’s perfect, and there’s always potential for mistakes.

Not only are peer code reviews a great way to great opportunities to ensure high-quality code, they also foster a positive culture of collaboration with your team.

The 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

Wrapping up and next steps

If you’ve made it this far, pat yourself on the back! Not everyone is so deeply invested in supporting their company’s codebase health and their team’s productivity.

If you care about doing a better code review, you truly care about the success of your team. Even if you don’t plan for it yet, your interest in supporting your team’s productivity means you also have the potential to be a great leader.

To help you go from being a team player to a team leader, we’ve created the course Become an Effective Software Engineering Manager. This course covers the essentials of impactful engineering management, including how to motivate your team, manage projects, and delegate tasks effectively.

Happy learning!

WRITTEN BYErica Vartanian

Join a community of more than 1.4 million readers. A free, bi-monthly email with a roundup of Educative's top articles and coding tips.

What are the 7 steps to review code?

What should a code review include?

What are the steps involved in code review process?

What are the 3 types of coding reviews?