Can code review be automated?

Apr 18 2023

Author: Andrey Karpov

Automated code review
The importance of implementation in the development process
Use advanced automated scanning tools
How to reduce false positives
Additional links

Code reviews can be automated with the help of static analysis tools. Keep in mind that one-off code checks are unproductive, so it is important to make static code analysis an integral part of the project development process.

1045_can_code_review_be_automated/image1.png

Automation of the code review process can mean two different things:

Tools that check code and issue warnings on those fragments that are likely to contain errors. In this article we'll look at just these tools.
Tools that help programmers organize code reviews. We won't talk about such tools in this article. These tools are in demand, for example, in distributed teams. See "Effective code reviews for distributed teams".

Automated code review

Code review is the process where developers review code together to identify bugs, security flaws, inefficient algorithms, and so on. This is a useful established practice, which unfortunately has two drawbacks:

It is expensive in terms of time and labor costs. It constantly distracts colleagues from their tasks, thereby reducing their time in the flow.
People may not notice some types of errors (e.g. typos).

To compensate for these drawbacks, an automated code review can be used. We are talking about static code analyzers. They become "team members" that perform a code review before other team members do.

The analyzer issues warnings about anomalies in code. By studying these warnings, a programmer can eliminate a number of bugs and security weaknesses, and improve the code layout. Thus, the static analyzer takes on part of the "dirty work" of detecting bugs. This allows programmers to focus more on finding high-level bugs rather than spotting typos during code review. Or spend more time discussing flaws in the design of classes.

The importance of implementation in the development process

Simply using a static analyzer is not enough. Developers make a mistake by running code analyzers on a case-by-case basis. This is an unproductive approach. The tools should be used on a regular basis — then many errors can be detected at an early stage of development. The earlier the error is found, the easier and cheaper it is to fix it.

This is why it is important to make automated code review part of the development process. Ideally, the check is run immediately after the code has been compiled. You can run the analysis when you commit code to version control systems (GitHub, GitLab, BitBucket, etc.). You can run it at night on the server. There are other scenarios. The most important thing is that these are regular processes!

Here's a good article on this topic: "Introduce Static Analysis in the Process, Don't Just Search for Bugs with It".

Use advanced automated scanning tools

In addition to regular use, it is very important to choose a suitable static code analysis tool. There is no universal advise for everyone. Different teams may need different tools. There are a lot of them (list of tools for static code analysis), and you can always choose something convenient for you.

Despite the fact that it is impossible to give a firm advice, I recommend first of all to pay attention to well-known commercial solutions. They generally provide a large range of functionality to suit many usage scenarios. Also, such tools tend to perform a deeper and better code analysis.

PVS-Studio is a case in point.

A good option is to check the code immediately after compilation. This is exactly what the PVS-Studio analyzer plugin can do. It is embedded in the Visual Studio, IntelliJ IDEA, Rider, CLion development environments (see incremental analysis mode).

Do you need to check the code when adding it to repository? It is possible: How to use PVS-Studio in GitHub Actions. You can run analysis in Docker, Jenkins, TeamCity and integrate the analysis results with SonarQube and so on.

As you can see, an advanced code review tool is easier to integrate into the development process. You may estimate the depth of code analysis by checking out the article "PVS-Studio: static code analysis technology".

How to reduce false positives

False positives can get in the way of implementing static analysis. There are situations when an analyzer generates warnings on code that is actually correct.

If you do nothing with false warnings, they do become a hindrance. Useful analyzer messages are drowned in false positives and are soon disregarded. A static analyzer becomes a burden. This usually occurs to teams that are less experienced and have not yet used static analysis, and do not know how to use the methodology correctly.

It's not enough to just start running the code analyzer, you need to configure it. This is also a part of the process of introducing the tool into the development process. Three main points for successful implementation:

Use modern static code analyzers whose developers focus on eliminating false positives.
Configure the static analysis. After that, the situation will change significantly and only about 10-15% of warnings will be false.
Check out the article "How to introduce a static code analyzer in a legacy project and not to discourage the team" and follow its the recommendations.

Clean code to you!