INTEGU uses cookies to personalize your experience and provide traceability for affiliate links. By using the website, you agree to these terms and conditions. To learn more see the privacy policy page.
Static Code Analysis
What is static code analysis?
Menu
What is static code analysis?
A static code analysis tool is a utility for analyzing the code without having to compile it. Without any compilation the analysis happens much faster than other tests which require compilation, for example unit tests. The goal of the analysis is to determine the language of the code, file by file, and afterwards inspect the code for misalignments with best practices.
Given that static code analysis does not require compilation of code, it also means that it can return a positive output even if the code is not able to run. However, regardless of this incorrect image of the codes quality, static code analysis tools should be able to bring value to the development of any project. Primarily due to its speed, and in some cases even automate analysis, it brings a consistent of code quality into all developers’ workflow. All developers work in different way. We all have our own favorite patterns and preferred utility classes to use, which without constant alignment, will resolve in an inconsistent code base. Inconsistent code is difficult to deduct the meaning and intentions from and will eventually lead to misunderstandings and errors. Static code analysis is therefore relevant to keep a consistent and aligned manifest of the rules and best practices, which all developers of a project should uphold.
Overview of Static Code Analysis Topic
- Code complexity
- Naming conventions
- Code duplication
- TODO locating
- Unused imports
- If-statement merging
- Lambda method replacement
- Catch-merging
- and many more….
Configuration of the tool
Most static analysis tools come in a preconfigured state with default rules enabled. In many situations I have seen developers install the new tool, happy with the result and simply continue developing with these default configurations. I believe that every time a tool is integrated into the development flow, it also needs to be configured to the needs and desires of that specific developer team.
My preferred method of configurations would be to allocate one or two developers from the project to walk through all possible configurations (perhaps across teams – assuming a large-scale project with multiple teams). For each configuration they should determine if a rule should or should not be enabled, or if the rule should be taken up for consideration on a larger team meeting. Finally, when all rules have been evaluated by the allocated developer(s), all enabled rules should be presented to the remaining developer and all undecided rules can at the same meeting also be discussed and determined if suitable for implementation.
Is static code analysis a testing tool?
Static code analysis tools should be considered a testing tool, since it output a positive or negative output based on the fulfillment of a set of rules from newly added code. It is perhaps true that it does not highlight the same level of errors as integration and unit tests does, whereas features are currently broken. However, it provides a much quicker analysis utility, which create a clear consistent in the code base.
Available Tools
When it comes to available tools, it is possible to find a wide range. Some of these tools provide the same functionalities, while others are unique in their functionality offering, and finally, some tools overlap a bit. Dependent on the preference of the team, more than one tool can be used, but it should always be considered if the already implemented tools could provide the desired functionality of new tools of consideration. Below a list of static code analysis tools can be found. I will encourage you to checkout every one of them to get an idea of what functionality the tools provide. The list is far from complete, so consider it a place to start the pursuit of the correct tool for your team.
- SonarLint
- SonarQube
- CheckStyle
- CodeScene (Checkout this blog if you want to learn more)
- Error Prone
- SpotBugs
- IDE (e.g. IntelliJ)
About
Hi, I'm the Author
My name is Daniel H. Jacobsen and I’m a dedicated and highly motivated software developer with a masters engineering degree within the field of ICT.
I have through many years of constantly learning and adapting to new challenges, gained a well-rounded understanding of what it takes to stay up to date with new technologies, tools and utilities.
The purpose of this blog is to share both my learnings and knowledge with other likeminded developers as well as illustrating how these topics can be taught in a different and alternative manner.
If you like the idea of that, I would encourage you to sign up for the newsletter.
Cheers! 🍺
