What is Static Code Analysis | Software Testing

The automatic analysis of source code without running the program is known as static analysis.

Dynamic Analysis is when the analysis is conducted while the program is running.

Static Analysis is frequently used to identify:

Vulnerabilities in security
Problems with performance.
Failure to meet standards.
Using obsolete programming constructs.

What is the function of a Static Analysis tool?

The fundamental idea shared by all Static Analysis tools is to search source code for certain coding patterns that have some type of warning or information connected with them.

"JUnit 5 test classes do not have to be 'public'," for example. Or something more difficult to recognize, such as "Untrusted String input used in a SQL execution query."

The way static analysis tools implement this feature varies.

Text Regular Expression matching
Source code parsing technology to generate an Abstract Syntax Tree (AST)

Regular Expression matching on text is incredibly versatile and simple to construct rules for, but it frequently results in a large number of false positives since the matching rules are unaware of the surrounding code context.

AST matching considers source code as computer code rather than merely text files, allowing for more detailed, contextual matching and perhaps reducing the amount of false positives recorded against the code.

Continuous Integration Static Analysis

During the Continuous Integration (CI) process, static analysis is frequently used to provide a report of compliance concerns that can be inspected to obtain an objective picture of the code-base over time.

Some individuals use static analysis to objectively test code quality by customizing the static analysis tool to just analyze specified areas of the code and report on a subset of rules.

The rules utilized ensure impartiality since they do not change in their evaluation of code over time. The combination of rules employed and their arrangement is obviously a subjective decision, and various teams opt to utilize different rules at different times.

While having Static Analysis conducted in CI is beneficial, it may cause feedback to the programmer to be delayed. Programmers do not receive feedback while working; instead, they receive input after running the code via the Static Analysis tool. Another advantage of performing the Static Analysis in CI is that the results are easier to dismiss.

It is normally feasible to specify a threshold metric in the build process to fail the build if the metric is exceeded, e.g. a lot of rules are triggered, to assist make teams pay closer attention to the findings of Static Analysis.

The IDE's Static Analysis

There are several IDE plugins that execute the Static Analysis rules in the IDE on demand or when the code changes to provide quicker feedback.

The rule infractions are thus visible in the IDE while the programmer writes code, and to make the rules more difficult to disregard, they are frequently configured to show as underlined code in the editor.

This is a wonderful approach for me to improve my coding, especially when working with a new library that is supported by the Static Analysis tool. Although it might be 'noisy' with false positives or rules you don't care about. However, this may be avoided by going the additional mile and configuring the Static Analysis tool to disregard specific restrictions.

Code Repair Using Static Analysis Rules

The mending of the rule is left to the programmer in most Static Analysis tools, therefore they must understand the source of the rule violation and how to repair it.

Because the repair is typically contextual to the team, the technology utilized, and their agreed-upon coding styles, very few static analysis tools also contain the option to fix the violations.

Default Regulations

Once the Static Analysis tools come with default rules, it's easy to imagine they address all the challenges a programmer could face and all the conditions that rule should apply. The conditions under which a rule should apply might be nuanced and difficult to determine at times.

The objective is that by utilizing a Static Analysis tool and thoroughly investigating the rules and infractions, programmers would be able to discover and prevent the issue in the context of their own domain.

When the domain necessitates contextual rules, the Static Analysis tools may not have any rules that fit your domain or library, and the tools are sometimes difficult to configure and grow.

Annoyances

These 'annoyances' are not insurmountable:

erroneous positives
a scarcity of repairs
adding context-specific rules
configuration to disregard rules

However, these are frequently cited as justifications for not utilizing Static Analysis tools in the first place, which is unfortunate because Static Analysis may be quite valuable as a technique to:

better techniques for younger devs
obtain immediate feedback on obvious coding faults
highlight unusual situations that the programmer has never faced before reaffirm the programmer's solid coding style (when no violations are reported)
Static Analysis Tools Using IDE
In order to get quick feedback on my code as an individual contributor, I like to utilize Static Analysis tools that run from within the integrated development environment (IDE).

This is in addition to any pull request review and CI integration that a project may have.

I look for products that will offer me an advantage and better my own workflow.

Because tools tend to have the same basic GUI and setup approach when executed in the IDE, it might be tempting to regard them interchangeably.

Although the tools may have overlapping functionality or rule sets, I install many programs to take use of their capabilities.

The following are the Static Analysis IDE tools that I actively use when coding:

IntelliJ Inspections - commonly used code patterns
SpotBugs - typical mistakes
SonarLint identifies frequent use patterns
CheckStyle identifies common style trends.
Secure Code Warrior's Sensei - custom rule creation

I use them all because they complement and compliment one another effectively.

Inspections in IntelliJ

If you use IntelliJ, you are already familiar with their Inspections.

These are the Static Analysis rules that are highlighted in the IDE. Some of them even feature QuickFix options for rewriting the code to fix the problem.

The rules may be toggled on and off, as well as the error level used to indicate it in the IDE.

There are several excellent IntelliJ Inspections. I am aware of this since I read them while writing this. This is why I don't utilize the IntelliJ Inspections by default, but rather look through them to find ones that apply to your coding style and raise the warning level to make them visible in the code.

The beautiful thing about IntelliJ Inspections is that they are included with the IDE and help establish muscle memory for:

detecting warnings and mistakes in the source as you write code, hovering the mouse over flagged code to understand the rule violations, and then using alt+enter to apply a QuickFix for the problem

SpotBugs

The SpotBugs IntelliJ plugin uses Static Analysis to detect flaws in your code.

SpotBugs may be configured to scan your code from the IntelliJ Preferences, and the exact criteria utilized can be discovered under the Detector tab.

After I've written and evaluated my code, I'll execute the 'Analyze Project Files Including Test Sources' command in SpotBugs.

This does aid in the detection of flaws, dead code, and apparent optimizations. It also compels me to look into some of the marked infractions in order to decide what to do.

SpotBugs will detect issues but will not provide any QuickFix instructions to attempt to remedy them.

SpotBugs is simple to set up, and I find it to be a valuable impartial second opinion in my IDE.

SonarLint

SonarLint is a plugin.

SonarLint may be enabled in IntelliJ Preferences to verify code against certain criteria.

SonarLint runs in realtime by default and displays bugs for the current code that you are changing.

Although SonarLint can not provide rapid remedies, the documentation associated with violation notices is typically straightforward and thoroughly documented.

In the past, I've found SonarLint beneficial for alerting me to new Java capabilities that I was unaware of in later versions of Java.

CheckStyle

The CheckStyle plugin includes formatting and code-quality requirements.

The CheckStyle plugin includes 'Sun Checks' and 'Google Checks.'

These definitions can easily be found online.

CheckStyle is most useful when a project has invested time developing its own ruleset. The IDE plugin may then be configured to utilize that ruleset, and programmers can run a scan before committing work to CI.

When the number of CheckStyle violations surpasses a certain level, CheckStyle is frequently used as a build failure plugin for CI processes.

Sensei Sensei matches code and creates QuickFixes using Static Analysis based on an Abstract Syntax Tree (AST), allowing for highly detailed identification of code with errors.

The AST enables QuickFixes connected with a recipe to comprehend the surrounding code; for example, when a new class is introduced to the code, any import for that class will only be added to the source file once, rather than for each replacement.

Sensei was intended to make it simple to establish custom matching rules that may not exist or would be difficult to configure in other tools.

Rather than editing a configuration file, all configuration may be done using the GUI. When adding new recipes, the GUI makes it simple to see which code the recipe corresponds to. Furthermore, while defining QuickFixes, the before and after states of the code may be easily compared. This makes it easy to construct highly contextual recipes, such as those specific to teams, technologies, or even individual programmers.

I use Sensei in conjunction with other Static Analysis tools, for example, most Static Analysis tools will detect but not repair errors. A common way to use Sensei is to copy the matching search from another tool and add to it with a Quick Fix. This has the added benefit of already meeting the code requirements for your project.

I find myself making Sensei recipes that already exist in the IntelliJ Intensions set on a regular basis since the Intension report doesn't exactly fit the context I've made or the QuickFix supplied by IntelliJ doesn't match the code pattern I want to utilize.

I supplement current tools rather than trying to completely replace them.

When you find a contextual variant of a common rule, for example, if you're using a SQL library that isn't supported by the Static Analysis tool but the common SQL rules in the Static Analysis engine still apply, you may use Sensei to build library-specific variants of those rules.

Unlike the Static Analysis tools mentioned, Sensei does not come with a large number of generic recipes; its strength is in making it simple to generate new recipes, replete with QuickFixes set to meet your individual coding style and use-cases.

NOTE: We are currently working on a public repository of recipes for generic use-cases, which you can discover here.

Summary

I prefer solutions that can be configured and expanded to match my individual needs. I've used the IDE's Static Analysis features for years to find bugs and learn more about the languages and libraries I use.

I utilize all of the tools described above in tandem:

IntelliJ Intentions helps detect common code bugs right away, frequently with QuickFixes.

SpotBugs detects trivial problems that I could have overlooked and alerts me to performance difficulties.

SonarLint reveals Java features I was unaware of and suggests other approaches to model my code.

CheckStyle assists me in adhering to a predefined code style, which is also enforced during CI.

Sensei assists me in developing QuickFixes to supplement typical cases discovered by Static Analysis tools and in developing customized project or technology recipes that would be difficult to set up in another tool.

Additional topics you might be interested in:

Business Tech News

What exactly is Static Analysis?

What is the function of a Static Analysis tool?

Continuous Integration Static Analysis

The IDE's Static Analysis

Default Regulations

Annoyances