How to do Code Review

Code reviews have become an integral part of modern software development. With a defined code review process, teams can not only spot problems early (when they're easier to fix), but also ship new features faster!

If you’re just starting out, or perhaps looking to improve your existing process, try following our simple rules for implementing a great code review process.


Copyright © Codacy. All rights Reserved.

What are Code Reviews?


Start shipping quality code today


By clicking "Sign up" I agree to Codacy's Terms of Service .

Wikipedia defines Code Reviews as a “...systematic examination of computer source code. It is intended to find mistakes overlooked in software development, improving the overall quality of software.”

Of course, the actual process and implementation of code reviews is a much more complex task! There's an implicit relationship between code quality and code reviews, so it's vital that you understand the best methodology to use, how it fits into the rest of your development process, and which team members take ownership of what.

Code reviews play an important part in the development process, but can often be a source of frustration, so follow these simple rules:

2. Setup a process

4. Work with team members

Errors can easily slip through if you work by yourself. By implementing peer code reviews in your development process, you ensure that more than one pair of eyes analyses the code. By doing this, you'll benefit from more effective code reviews, and find new solutions that could have easily been missed if only seen by a single developer.

You might also want to look at letting all of your developers review code from time to time. It brings a sense of ownership and is a great way to spread knowledge across junior team members. On average, developers should spend between 0.5 - 1 day per week reviewing code.

5. Reporting and fixing bugs

Code reviewing isn't just about the review. The way you report and fix bugs is just as important. That's why you'll need a well structured reporting and fixing process. 

For reporting bugs, it's vital to establish what information is important for the programmers. It's also important to define who will be responsible for analysing and prioritising those bugs so you can reduce confusion and wasted effort.

When looking at fixing bugs, you should be clear at what stage of the process the bugs will be addressed and how they might affect pull requests.

6. Choose the right tools

Even if you had all of your programmers reviewing your source code, mistakes will undoubtedly slip through! Unfortunately, the traditional code review processes can be laborious and time consuming. Some teams might even avoid running code reviews purely because of the perceived time wasted, versus the benefits gained.

Code review tools such as Codacy strive to make the code review process easier through automated analysis, so your team can be more efficient, and improve code quality.

One of the biggest pitfalls is not establishing a documented code review process. This means that team members don't understand where, when, or why they should review code. Without it, teams can even be mistaken into thinking that the process is actually counter productive, rather than beneficial.

Establish a process that works best for the size of your team, their needs, and level of communication. Establish owners of the code review process, who will conduct the reviews, and who will benefit most from the code reviews.

To help you set-up your own process, try the OWASP Code Review Guide Table.

Even the high-level developers on your team can make mistakes when reviewing the code base. The best way to reduce the probability of errors is to use a checklist that takes into consideration the standards and quality that have been established for your product. We've found that teams that have a quality standards checklist actually spend less time fixing bugs and more time building new features

It is also a great way to keep control of what's been done, and what still needs to be reviewed.

1. Review early. Review often

Many organisations run their code reviews at the end of the development process. This might seem logical, but it's not actually the most efficient approach. Having worked with hundreds of development teams around the world, we've found that the teams that run code reviews before deployment, actually spend the least amount of time fixing bugs and making code changes. That's because, by running code reviews earlier in the process, teams are able to improve productivity by identifying issues before programmers waste time building more code on top of already broken code.

So, by reviewing early, and reviewing often, you can reduce code changes and simplify developer peer reviews.

TL;DR (Cheat Sheet)

An efficient code review  process  improves code quality, and creates more productive, and happy engineers.
So just remember our simple rules for a good  code review practice:   

  1. Run code reviews early and often to identify issues as early as possible.    

  2. Have a well-documented code review  process  and share it with the team so everyone understands its importance.     

  3. Establish code quality standards for your product and create a checklist that everyone can refer to.    

  4. Implement peer reviews, and make sure all your developers get to review code.    

  5. Document the process for reporting and fixing bugs so that everyone understands how they might impact pull requests.    

  6. Manually reviewing code is time consuming, laborious, and error-prone. Find tools that will drive greater accuracy and efficiency.

Setting up a proper code review workflow might seem like a complex task at first, but by addressing this process early on, you guarantee better results in the long-term. For a more detailed guide, with recommendations drawn from interviews with almost 700 developers, download our “Ultimate Guide to Code Review”.

If you're ready for a better way to review code and improve code quality, try Codacy for free.