One of the most common questions from software engineers regarding Codacy is “Automate Code Review? Really? How can this work?”
(Peer) Code Review established itself as a common best practice in modern software engineering workflows. However, if you ask engineers they will tell you that often 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 show you how static analysis can save up to 70% of the time spent in code review (even with using just one tool like Codacy).
What is Static Code Analysis?
Static code analysis is a way to analyze code without executing it (the opposite of 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.
Automate Code Review: How to use Static Analysis the Legacy Way?
1. Run Open Source Tools On Your Machine
One of the most common ways to apply static code analysis is to run static 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 a project.
Here is a sample of great tools that you can use today:
- Java: PMD, Checkstyle, Findbugs
- Scala: Scalastyle, Wartremover, Abide or see our Review of Scala Static Analysis Tools
- PHP: PHP Mess Detector, Code Sniffer, PHPCPD or see our Review of PHP Static Analysis Tools
- JavaScript: ESlint, JSHint or JSLint
- Python: Pylint, Pyflakes, Mypy or see our Review of Python Static Analysis Tools
- Ruby: Rubocop, Brakeman, Reek or see our Review of Ruby Static Analysis Tools
- C++: Cppcheck, Clang
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 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 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. However, this does not adapt to short development lifecycles and code review practices.
2. In Your Editor
Many 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:
- 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 is that it’s impossible to enforce in teams. The best engineers will probably respect it, but then you will have people who 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-saver in code reviews if, and only if, everyone in the team complies to the same rules. This is unfortunately often not the case. The bigger the team, the harder to manage. Check out “Seven Drawbacks Of Linting Tools.”
3. In Your CI (Continuous Integration) Tool
One way to integrate static analysis in your development process is to add tools to your continuous integration pipeline. Most tools have plugins that you can easily integrate with common continuous integration tools.
Pros:
- 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 code review
It is the above points that motivate us every day to develop Codacy. We believe that static code analysis can save time, money and (a lot of) frustration for software engineering teams. This is how continuous static code analysis can help you automate your code review:
1. Focus On What Really Matters
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.
It gives you the impact on key additional metrics on every commit and pull request: Code Coverage, Code Complexity or Code Duplication:
2. Development Process Integration
Codacy only analyzes the code diffs. Therefore it is much faster than just running tools on your complete code base. No more waiting 1h to run one single tool on your big Java or PHP repo. 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.
3. 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.
4. Enforces Coding Standards 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. Empowers Engineers to Improve Skills
It does even more than just playing the code review bot for you. Codacy 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.
Conclusion
Static Analysis, if used properly, can be an effective way to automate code review. 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!
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.