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.
Automation of the code review process can mean two different things:
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:
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.
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".
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".
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:
Clean code to you!