Rules and languages

The Sonar rules catalog is the entry point where you can discover all the existing rules. While running an analysis, SonarQube for IDE raises an issue every time a piece of code breaks a coding rule. Software quality classification and severity show the impact of the issue on your code.

See the Software qualities page for more information about these classifications.

Overview

SonarQube for Eclipse provides analysis for several languages. Support for your language may vary depending on the SonarQube for Eclipse version you’re running.

The table below lists the supported language and language versions. For each language version, the level of support is defined as follows:

• Fully supported: The analysis will complete. All the language features are understood and examined.

• Supported: Most language features are understood and examined but the version includes unsupported features. Analysis might break or provide incomplete results.

For language-specific properties, refer to the relevant language pages in the SonarQube (Server, Cloud) or SonarQube Community Build docs directly; the same Sonar language analyzers are used by SonarQube for Eclipse.

• Languages in SonarQube Server

• Languages in SonarQube Cloud

• Languages in in SonarQube Community Build

Supported out of the box: SonarQube for IDE automatically checks your code in these languages and formats. Connected mode required: Running in Connected mode with SonarQube (Server, Cloud) unlocks analysis for these languages and formats.

The full list of available rules is visible in the Rules Configuration preferences tab found by navigating the UI to Window > Preferences > SonarLint (or Eclipse > Settings… > SonarQube for Mac OS) for access to Rules Configuration. Here you can activate and deactivate rules to match your conventions. SonarLint will also show a code action on each issue to quickly deactivate the corresponding rule.

For more details about languages and new features under consideration for all versions of SonarQube for IDE (including Eclipse), please refer to the SonarQube for IDE roadmap where we list our coming soon and newly released features.

Rule selection

Sonar Rules can individually be turned on or off while running SonarQube for Eclipse in standalone mode; there are two ways to do this:

• Right-click on the issue and select the Remove rule quick fix in the tooltip.

• Activate and deactivate rules one by one in the SonarQube Preferences > SonarQube > Rules Configuration menu. A full list of rules organized by language is available.

When your project is bound to SonarQube (Server, Cloud) or SonarQube Community Build using Connected mode, the rule set is managed on the server side as defined by the quality profile.

Sonar Rule Descriptions

The SonarQube Rule Descriptions view is usually your first step in identifying why you have an issue. Right-clicking on any issue in a SonarQube for Eclipse view, or exposing the tooltip and selecting Open description of rule… in the code editor will open the SonarQube Rule Descriptions view.

The Rule Descriptions include information about why this causes an issue and noncompliant/compliant code snippets are usually offered. More serious issues such as security hotspots and injection vulnerabilities often include information about why it’s an issue and what is the potential impact.

SonarQube for Eclipse supports syntax highlighting; its availability is dependent on the Eclipse version and plugins you have installed; note that JDT is required for Java syntax highlighting. Currently, syntax highlighting for Java and C / C++ languages are available.

Syntax highlighting is not available for languages accessed with external plugins, but an extension point is provided to plugin developers. More information on extension points will be coming soon…

Understanding issues in your IDE

An issue’s coding attribute, software qualities, and severity are presented to you when opening the SonarQube Rule Description view. Below the rule title, you will find the coding attributes that highlight an issue’s classification. Check the SonarQube glossary page for details about coding attributes, and the Software qualities page to better understand software qualities for more details about how they help classify your issue.

When in connected mode

If you’re running SonarQube for Eclipse while in connected mode with SonarQube Server or SonarQube Community Build, your view will change according to the server settings. Standard Experience mode encompasses the use of rule types such as bugs, code smells, and vulnerabilities. Alternatively, if SonarQube Server is set to Multi-Quality Rule mode, you will more accurately represent the impact an issue has on all software qualities.

Please see the pages about the MQR mode and Standard Experience for detailed information about the available rule modes for your instance:

• Choosing a mode for your instance in SonarQube Server

• Choosing a mode for your instance in SonarQube Community Build

Applying rules while in connected mode

Connected mode syncs your SonarQube (Server, Cloud) or SonarQube Community Build quality profile with the local analysis to suppress issues reported in the IDE.

Language-specific requirements

C and C++ analysis

Analysis of C and C++ code in SonarQube for Eclipse requires a C/C++ Development Tool (CDT) ; you can check the Eclipse Embedded CDT documentation for more details.

Note that you might need to build your C/C++ project successfully once in the IDE in order for CDT to configure everything properly and for SonarQube for IDE to pick up this configuration for the analysis.

For instructions on how to configure a C/C++ project project, refer to the Eclipse CDT documentation.

COBOL

COBOL analysis requires a COBOL IDE based on the Eclipse platform such as the IBM IDz or BMC IDEs. Note that recent versions of SonarQube for Eclipse and our analyzers have a few Requirements in order to run, and IBM IDz only supports JRE 11 starting from version 16.

• Check the IBM documentation for more information about SonarLint integration with Developer for z Systems.

• Some additional information is available for setting up a SonarQube for Eclipse with your BMC Compuware Topaz Workbench.

Java and JSP

Analysis of Java code requires the Eclipse sub-project Java development tools (JDT). This includes a Java compiler, incremental builder, editors, wizards, content assist, and all the other features of a first-class Java IDE.

JavaScript, TypeScript, and CSS

Node.js is required to enable JavaScript, TypeScript, and CSS analysis.

• When the Eclipse Wild Web Developer plug-in is installed in the IDE, SonarQube for Eclipse tries to leverage the plug-in’s bundled Node.js installation, if the requirements are met.

• If needed, you can manually set your Node.js executable. The JavaScript and TypeScript analysis article details how to set a path to your Node.js.

Other rule types

DBD rules

Dataflow bugs are a set of complex Python and Java bugs that are only detected when reviewing all feasible execution paths. This type of issue can cause runtime errors and crashes in Python and Java. If you want to learn more, check out our blog post for a good explanation with an example.

Dataflow Bug Detection (DBD) rules for Python and Java are supported in Commercial editions of SonarQube Server and by SonarQube Cloud. At this time, SonarQube for Eclipse supports DBD detection for Java and Python when running in connected mode with SonarQube Server Active Versions or SonarQube Cloud.

Injection vulnerabilities

Security vulnerabilities requiring taint engine analysis (Injection vulnerabilities) are only available in connected mode because SonarQube for IDE pulls them from SonarQube (Server, Cloud) following a project analysis.

To browse injection vulnerabilities in SonarQube for Eclipse, set up Connected mode with your SonarQube Server or SonarQube Cloud instance. Once a Project binding is configured, SonarQube for Eclipse will synchronize with the SonarQube (Server, Cloud) to report the detected injection vulnerabilities.

More information about security-related rules is available in the server documentation:

• Security-related rules in SonarQube Server

• Security-related rules in SonarQube Cloud

Security hotspots

SonarQube for Eclipse does not detect security hotspots on its own, and does not report the hotspots found by SonarQube Cloud. However, SonarQube’s Open in IDE feature will open one hotspot at a time in Eclipse and show them in the SonarQube Security Hotspots view window.

Please see the SonarQube for Eclipse documentation on Security hotspots for more details, and the Investigating issues page to learn about Opening issues in the IDE using the Open in IDE feature.

Secrets detection

Secrets are pieces of user-specific or system-level credentials that should be protected and accessible to legitimate users only. SonarQube for Eclipse detects exposed Secrets in your source code and language-agnostic config files. When running in connected mode, the SonarQube (Server, Cloud) or SonarQube Community Build quality profiles are applied to locally detected Secrets.