Rules and languages

The Sonar Rules catalog is the entry point where you can discover all the existing rules. While running an analysis, SonarLint raises an issue every time a piece of code breaks a coding rule. 

Issues in your code are linked to Clean Code code attributes. When an issue is detected, it signifies that this part of your code is not consistent, intentional, adaptable, or responsible enough and that it impacts one or multiple software qualities. 

For more information about Clean Code attributes and software qualities, check out the Clean Code introduction page.

Overview

SonarLint for the JetBrains family IDEs currently supports the following programming languages:

Language	IntelliJ IDEA & Android Studio	CLion	Rider	(DataGrip, Php Storm, PyCharm, RubyMine, and WebStorm)
C#
C/C++
CloudFormation
CSS
Docker
Go	(Go extension)			(GoLand)
HTML
Java
JavaScript
Kotlin
Kubernetes
PHP
PL/SQL	(Database Tools extension)	(Database Tools extension)		(Database Tools extension)
Python
Ruby
Scala
Secrets
Swift
Terraform
TypeScript
XML

In addition, SonarLint for IntelliJ supports the IaC domains for:

Language	IntelliJ IDEA & Android Studio	CLion	Rider	(DataGrip, Php Storm, PyCharm, RubyMine, and WebStorm)
Cloud formation
Docker
Kubernetes
Terraform

For more details about languages and new features under consideration for the JetBrains family IDEs, you can refer to the SonarLint roadmap where we list all of our coming soon and newly released features.

Rule selection

The full list of available rules is found by navigating to the IntelliJ Settings... > Tools > SonarLint > Rules tab. There, Sonar Rules can individually be turned on or off while running SonarLint in standalone mode; simply select or deselect the appropriate checkbox. 

When your project is bound to SonarQube or SonarCloud using Connected Mode, the rule set is managed on the server side as defined by the quality profile. 

Sonar Rule Descriptions

Simply select an issue in the SonarLint view or choose SonarLint: Show rule description from the tooltip to open the Rule tab. Here, you will find a brief explanation of the rule as well as Noncompliant and Compliant code samples.

SonarLint for IntelliJ supports syntax highlighting. In addition, users are able to visualize a diff view for the non & compliant code samples which should help you fix your issue. Note that diff highlighting is only available for rules descriptions migrated to the new format, and we're progressively migrating all existing rules to the new format.

An issue’s Clean Code attribute, software qualities, and severity are presented to you when opening the SonarLint > Rule tab. Below the rule title, you will find the Clean Code issue badges that highlight an Issue’s Clean Code classification. 

Check the Clean Code definition page for details about Clean Code attributes, and the Clean Code benefits page to better understand software qualities for more details about how they help classify your issue. 

Be sure to check out the Investigating issues page for more details about how issues appear in your IDE. 

Applying rules while in Connected Mode

Connected Mode syncs your SonarQube or SonarCloud Quality Profile with the local analysis to suppress issues reported in the IDE. Therefore, when running in Connected Mode, SonarLint will ignore rule settings that are defined locally. See the Connected Mode page for more information about running Connected Mode.

C# analysis

The SonarSource C# analyzer is written as a Roslyn analyzer and requires the use of the JetBrains Rider IDE.  Please see the Supported features in Rider article for more information.

Go

SonarLint for IntelliJ will check your code against Go rules using either GoLand or the Go plugin extension for IntelliJ.

JS/TS/CSS analysis

The analysis of JavaScript, TypeScript, and CSS code requires Node.js >= 16; Node.js >= 18 is recommended.

PL/SQL analysis

The support for PL/SQL analysis is only available together with Commercial Editions of SonarQube or with SonarCloud when running in Connected Mode. In addition, the Database Tools extension is required to complete the local analysis in IntelliJ IDEA, CLion, or WebStorm.

Other rule types

Injection vulnerabilities

Security vulnerabilities requiring taint engine analysis (taint vulnerabilities) are only available in Connected Mode because SonarLint pulls them from SonarQube or SonarCloud following a project analysis.

To browse injection vulnerabilities in SonarLint for VSCode, configure Connected Mode with your SonarQube Developer Edition (and above) or SonarCloud instance. Once a Project Binding is configured, SonarLint will synchronize with the SonarQube or SonarCloud server to report the detected injection vulnerabilities.

More information about security-related rules is available in the SonarQube or SonarCloud documentation.

Security hotspots

In SonarLint for IntelliJ, local detection of Security Hotspots is enabled if you are using Connected Mode with SonarQube or SonarCloud.

Please see the SonarLint documentation on Security hotspots for more details.

Secrets detection

Secrets are pieces of user-specific or system-level credentials that should be protected and accessible to legitimate users only. SonarLint detects exposed Secrets in your source code and language-agnostic config files. When running in Connected Mode, the SonarQube or SonarCloud Quality Profiles are applied to locally detected Secrets.