Avoid common mistakes during the review and focus on the correct areas by implementing automatic checks and writing tests. If you and your team are not already reviewing code changes, I can highly recommend to first read How To Implement Code Reviews In Your Team written by Daniel Thysell.


By combining all techniques and methods in this article when reviewing the code, you as the presenter of the code can feel safer that your code is not only working but also is good. This will also be very welcomed by your team members who are going to be presented by a clean and well tested code already at the first code review session. The review will go smoother and be much more efficient, so less time and energy is spent on problems that should have been detected before the review and the actual review session can focus on the important parts such as functionality and potential problems.

Continuous Integration is your friend

Ideally each developer works on their own branch. This might be more or less an easy way of working depending on which file revision system is used. For example git is a file revision system which encourages developers to use separate branches for every task since creating a branch is really quick and light weight. By working on a separate branch it should always possible to push your work to your Continuous Integration (CI) machinery and get a report as feedback before any code review.

Code style checks

Choosing a tool that works in the terminal is usually a good start to be able to integrate the tool with your CI system. For C++ code there are a lot of code style tools for example AStyle or C++lint and for Python code a popular tool is PEP8. Let the CI system run all the automatic checks and report the result. So when calling to a review request your code is already checked for code style mistakes and so on which means the review can be about the important part of the change, such as how well the change integrates with the whole system and other potential problems that humans are better at detecting than the average CI system.

Unit tests

By writing unit tests and especially if you put a real effort in writing unit tests all the corner cases have been already found by you and fixed before the review of the code. And similar to the code style checks, the unit tests should of course also be run by the CI before the review.

Commit hooks

As a compliment to using the CI to check for style violations or failing unit tests, you as developer should be able to run these checks locally. But it is always easy to forget, so to avoid pushing code that could cause the CI to find a fault, it can be very convenient to use so called commit hooks. Hooks are supported by most file revision systems and these hooks are usually a script file that is triggered for example before a commit or push. The hook script can be designed to run the appropriate style checks and unit tests, if any of the checks fails the file revisions system could prevent committing or pushing the code change.


Code reviews are a great way to share knowledge, as Daniel Thysell also mentions, both for the other team members that becomes involved in the change and the team members can also inform about for example unexpected side effects that might have been missed, since all team members have different approaches and experiences. Therefore it is preferable if all team members are involved in the review. And remember that all bugs and potential problems that are fund during the review session are much cheaper to fix before committing rather than fixing later, usually that is a factor 10 in effort to fix problems in later stages, more about this can be read in Why Software Reviews Are Like Broccoli.


By adding automatic style checks and write unit tests the review session can be much more efficient since the reviewers can focus on the actual function of the code already in the first review session. This also leads to higher code quality and therefore much less effort and money have to be spent later on found bugs in your product.

Hopefully this gave you some insight how to improve your team’s code review workflow and do not hesitate to contact me how your team performs reviews or with feedback about this article.