Getting the most out of a code review

Code reviews are most of the time introduced within a team to have an additional pair of eyes. Developing is a human practice, hence can lead to mistakes. When you’re developing a piece of code, you can miss things like wrong assumptions regarding your design or code that might cause issues. Things that your peer might address.

If you as a developer put your work to review, it feels like that you have to go to a jury and people will judge your work. Although this could feel like this, it is also an opportunity for you to grow as a developer. Other people might have different insights and give you hints and tips to different solutions. It will also catch up issues and typo’s in upfront before delivering.

What does it take to have a productive and good code review? It first starts with good preparation; knowing what the code does and behave before actually starting to review it. Then we can wrap it up and give the reviewer some suggestions that he can look at, without being aggressive.

Let’s go through these steps and look them into detail with some suggestions how to tackle them.

Review preparation

Know what the code does

This might sound trivial, but when starting a code review you have to know what the code you are going to review is actually doing. In this way you more easily will see the patterns and identify possible design issues. Also interface definitions become clearer.

Test the code

Check out the code locally and play around with it. See if the functionality implemented by the code reviewed is actually doing what it should do. Also try out corner cases and check if the code also covers this. This is a part of the developer testing.

The actual code review

Finding the usual suspects

When I start reviewing code, I will first try to spot the usual suspects; did one thought of checking for null-references? Are exceptions caught at the right level? Are preconditions checked?

Also are unit tests written for the code you’re reviewing? By looking at the unit tests, you can already understand a lot of what the code is doing you are reviewing. This also will help the reviewing process.

Use code guidelines as a guidance

Use the code guidelines as a source. They can give you guidance for the code review. You can also use static code analysis tools for find a lot of construction issues, which can be caught in a code guidelines document, and warn the developer beforehand.

Use a review checklist

A guide guideline checklist can help the team to speed up the reviewing process and make it really effective. They can go through the list and verify each of the points one by one. Especially for junior developers it can be beneficial, because they don’t often know how and where to begin a code review.

Easy things that can be verified are:

  1. Code formatting
    Think of the fact if variables are using the naming convention which is agreed upon.
    Is the code using the agreed maximum line length? Think of reviewing on a screen, so two files can be opened without scrolling from the left to the right over and over again.
    Are all commented out code removed?
    Are there no unneeded comments?
  3. Design
    Is the code using best practices?
    Does the code follows the defined architecture?
    Is the code at the right level of abstraction?
    Are design patterns applied well?
  4. Naming
    Have methods a appropriate name?
  5. Code safety
    Check if the scope of a variable or class is not to wide, i.e. private or internal in fond of public.
    Is the code written in a defensive way?
    If you use third party libraries, do you catch all the exceptions and all other error conditions?
  6. Testable
    Is all added code tested by unit tests?

Wrapping the review up

Now you’ve reviewed the code, it is completing your review and giving the results back to the person who asked you to do the review.

Don’t offend people with your code review

A code review is intended to solve issues before they’re integrated within the software archive. Because pointing out a potential fault to the originator, can heart. The objective, however should be that it prevents error in the code and you can educate the developer in such a way the same errors won’t easily happen in the future again.


When concluding the code review, report back to the person requested the review what you think should be corrected and things that could be improved. There is always a thin line between the two, but mayor errors like design issues or code that doesn’t work off course belongs to the first group. Renaming stuff and things like that, most of the time belong to the second group.

Mention that you’re done

Let the person who requested the review know that you looked at his or her code, so issues can be addressed and updated.

If needed repeat the process

When needed and you don’t agree all upon the fact that all issues are covered, start the process over again.

How to continue

Code guidelines within a team should be agile. If you see a common error is happening over and over again within the team and can be easily prevented by doing a proper unit test, you should add this defend within your process.

Remember the having a code review, doesn’t safeguard you from not having to test your code. But by having an additional pair of eyes to it, a lot of issues might be prevented. Also having design sessions in front up your development will eventually eases your reviewing process, since design mistakes will be addressed before the actually development has even started.

Posted in Best practices, Scrum by Bruno at October 24th, 2019.

Leave a Reply