Automate Your Code Reviews with Static Code Analysis

One of the most common questions I have to answer software engineers when talking about Codacy is “Automated Code Reviews? Really? How can this work?”.

(Peer) Code Reviews established itself as one the common best practice in modern software engineering workflows. But if you ask engineers they will tell you that most of the time code reviews are about enforcing best practices, code style, and common security issues. 100% of those issues can be found by static analysis and linting tools. In this article, we will see how you can use static analysis to save up to 70% in code review time.

What is Static Code Analysis?

Static code analysis is a way to analyze code without executing it (in opposite to dynamic code analysis). Most of the time code is parsed into an intermediate code representation that can more easily be checked. JSON in JavaScript or astroid for Python are only a few examples.

Static Code Analysis finds a wide range of issues: code style, code best practices, security, complexity, compatibility etc.

How to use Static Analysis the legacy way?

1. Run tools on your machine

One of the most common ways to apply static code analysis is to run static code analysis tools on top of your code manually or semi-manually. Just run one of the dozens of open source tools on your repo and get a list of all the issues found in your project.

Here is a small selection of great tools that you can use today:

Pros:

  • It’s easy to use
  • It’s free

Cons:

  • You need to run it manually
  • It’s impossible to prioritize the issues: You found hundreds (thousands?) of issues in your repositories, what now? What issues should you tackle first?
  • It can’t be enforced in teams
  • You can’t track it over time and centralize the results of your different tools
  • It slows your development: On bigger projects running one tool can easily take tens of minutes, let alone if you need to run several tools

If you run these tools or use some expensive solution to centralize these results, you won’t be able to save time in code reviews. It will tell you all the issues that you have in your project but this is not adapted to short development lifecycles and to the practice of code reviews.

2. In your editor

A lot of linting and static code analysis tools have integrations with editors, that allow you to directly check your code before committing it.

Some examples are the Scalastyle plugin in Eclipse, the ESLint integration in Sublime or the Pylint integration in Emacs.

Pros:

  • It’s extremely easy to use
  • It’s fast
  • You get feedback directly in your editor and can implement fixes faster
  • It’s great for engineers working alone on projects
  • It’s free

Cons:

  • The biggest problem with that solution is that it’s impossible to enforce it in teams. The best engineers will probably respect it, but then you will always have people that don’t comply. It’s difficult to share configurations across teams and, therefore, enforce a common coding standard
  • You can’t track your quality over time or get reports
  • You can’t prioritize the issues

Using linting and static code analysis in your editor can be a huge time-savior in code reviews if, and only if, everyone in the team complies to the same rules. This is unfortunately not often the case and the bigger the team gets, the harder it is to manage it.

3. In your Continuous Integration Tool

One way to integrate static analysis in your development process is to add tools in your continuous integration pipeline. Most of the tools have plugins that you can easily integrate with the most common continuous integration tools.

Pros:

  • It has the advantage that it runs automatically without manual trigger and across all the code base
  • With some additional plugins you can even track the issues over time and get reports
  • With these same plugins, you could even get an overview of the number of new and fixed issues for every build

Cons:

  • It’s a pain to manage and maintain
  • It’s slow: tools are running one after the other and can easily take 30 mins per tool on larger code bases which slows you down
  • It’s already too late: getting all these issues in the build process is already too late. From all the teams I talked to using that process, they will either 1. break builds for non-compliance, slowing down even more the process and frustrate engineers or 2. just ignore them

Running your static analysis tools in your continuous integration tool has some advantages. But in the end, it’s not really adapted to modern workflows. It is the relative cost to fix a bug depending on development stage it is found (inter alia), that pushed for development processes that include a bigger code review part. Running static analysis tools in your continuous integration pipeline (and even sending those results to Sonar) will definitely not help you save time in your development process.

Using Static Analysis to automate your code reviews

It is the above points that motivate us every day to develop Codacy. We believe that static code analysis can be used to save time, money and (a lot of) frustrations to software engineering teams. This is how continuous static code analysis can help you automate your code reviews:

1. Focus on what really matters to you

Codacy will only show you the new issues introduced or fixed, and not the issues introduced 2 years ago, that already got reviewed 20 times. Review issues that were introduced by yourself or by the colleague you need to review.

New and fixed Issues in Codacy

It gives you the impact on key additional metrics on every commit and pull request: Code Coverage, Code Complexity or Code Duplication:

Key Software Metrics Codacy

2. It integrates with your current development process

Codacy only analyzes the code diffs and is, therefore, much faster than just running tools on your complete code base. No more waiting of 1h to run one single tool on your big Java or PHP repo. But most importantly it integrates where developers already spend time reviewing code: Pull Requests and commits. Codacy directly pushes new issues found on Github, Bitbucket or Gitlab Pull-Requests.

Github Codacy Comment

3. It’s easy to manage and maintain

No more headaches managing configurations files or dependencies. Everything is centralized and enforced across your projects in a single interface.

Code Patterns on Codacy

4. It enforces your coding standard automatically

Codacy is a Code Review Bot so you don’t need to be one and can focus on other things. How many times did you comment “Variables are not in CamelCase” or “Please put double quotes in your Strings” in your career? No more headaches making sure your team and colleagues respect the same standard, run the right tools with the proper configurations. No more ignored reports in a build pipeline.

Everything is centralized and works automatically on a post-commit level.

5. It empowers engineers to improve their skills

It does even more than just playing the code review bot for you. It even helps engineers become better at their job. For every issue found, Codacy will also provide some documentation on “Why is this an issue” and link it to external resources (from blog articles, StackOverflow questions to documentations) to help developers actually fix those issues.

Issue Detail Codacy

Conclusion

Static Analysis, if used properly, can be an effective way to automate your code reviews. Code reviews shouldn’t be about code style, best practices or common security issues.
To the question “Can Static Code analysis automate 100% of my code reviews?”, the answer is, of course, “not yet”.
But, at Codacy, our customers are seeing time savings in code reviews at up to 70%! Try it out today!


Edit: We just published an ebook: “The Ultimate Guide to Code Review” based on a survey of 680+ developers. Enjoy!


About Codacy

Codacy is used by thousands of developers to analyze billions of lines of code every day!

Getting started is easy – and free! Just use your  GitHub, Bitbucket or Google account to sign up.

GET STARTED

Best Practices

Related Articles