Rules and languages
The rules and languages supported by SonarQube for VS Code.
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. To see a full list of Sonar rules, check the Rules page of your SonarQube Server instance or in your SonarQube Cloud organization.
See Software qualities for more information.
Overview
SonarQube for VS Code currently supports the following programming languages:
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) or SonarQube Community Build unlocks analysis for these languages and formats.
Apex rules
Azure Resource Manager rules
C rules
C++ rules
C# rules
COBOL rules
CSS rules
Go rules
HTML rules
Java rules
JavaScript rules
PHP rules
PL/SQL rules
Python and IPython notebook rules
Secrets detection rules
Text
TypeScript rules
T-SQL rules
XML
In addition, SonarQube for VSCode supports the IaC domains for:
Ansible
CloudFormation
Docker
GitHub Actions
Kubernetes
Terraform
The full list of available rules can be found in the VS Code UI. See the article below about Using Sonar rules for details. Open the Supported language versions expandable to learn how to see which versions are supported for a given language.
Supported language versions
SonarQube for VS Code provides analysis for several languages. Support for your language may vary depending on the SonarQube for IntelliJ version you’re running.
For language-specific properties and supported language versions, 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 the servers are used by SonarQube for IntelliJ.
There are commercial-level rules available in SonarQube Cloud (all plans) and in SonarQube Server. For these rules to appear in SonarQube for IDE, it must be in connected mode. See Commercial-level rules for more information.
For more details about languages and new features under consideration for VS Code, check out the SonarQube for IDE roadmap where we list our coming soon and newly released features.
Sonar Rule Descriptions
Simply right-click an issue in the PROBLEMS Panel, and choose SonarQube: Show issue details for `…` to open the SonarQube Rule Description webview. Here you will find a brief explanation of the rule, along with a noncompliant and compliant code example. For more information, see the server documentation about quality profiles:
Managing quality profiles in SonarQube Server.
Managing quality profiles in SonarQube Cloud.
For some SonarQube Rule Descriptions, you can visualize a diff view for the noncompliant and compliant code sample, which should help you fix your issue.
An issue’s coding attribute, software qualities, and severity are found when opening the SonarQube Rule tab. Below the rule title, you will find the coding attributes that highlight an issue’s classification. Check the SonarQube glossary for details about coding attributes, and the Software qualities page to better understand how they help classify your issue.
When in Connected Mode
If you’re running SonarQube for VS Code 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. See the Connected mode documentation for more information.
Language-specific requirements
See the Language-specific requirements on the Requirements page.
Rules for AI CodeFix
A select set of rules are eligible for AI CodeFix when running in connected mode. Please see the Rules covered with AI CodeFix article for a full list.
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. At this time, SonarQube for VS Code supports DBD detection for Python when running in connected mode with SonarQube Server Active versions; support for DBD detection in Java is under development.
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 VS Code, configure Connected mode with your SonarQube Server or SonarQube Cloud instance. Once you Configure your binding, SonarQube for IDE will synchronize with 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
In SonarQube for VS Code 3.14 and above, local detection of Sonar Security Hotspots is enabled if you are using Connected mode with SonarQube Server 2025.1+, SonarQube Cloud, or SonarQube Community Build.
Please see the SonarQube for IDE 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. SonarQube for IDE 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.
Commercial-level rules
There are commercial-level rules that are only available in SonarQube Cloud (all plans) and SonarQube Server. The list of Sonar rules available found on the Rules page of your SonarQube Server Developer, Enterprise, and Data Center editions or in your SonarQube Cloud organization may be different than what you see in the IDE.
In order for these rules to appear in SonarQube for IDE, it must be in connected mode. In the standalone mode these rules are not visible. See Connected mode for more information.
Commercial-level rules are not available in SonarQube for Community Build.
Using Sonar rules
When not running in connected mode (also known as standalone mode), all Sonar rules for your language can be configured in the IDE. In addition, some Sonar rules have parameters that you can modify. Here are a few reasons you might want to edit a rule locally:
Disable a rule that is enabled by default. Maybe the rule doesn't apply to your specific project. See Rule selection for more information.
Enable a rule that is disabled by default. By reviewing which rules are disabled, you might notice that some rules could be useful in the context of your project. See Rule selection for more information.
To improve a rule. In some cases rules have parameters. For example, regarding cognitive complexity, you can customize the threshold at which the rule will raise issues. See Edit rules for more information.
Rule selection
The full list of available rules is found by navigating to the SONARQUBE SETUP > RULES view in the VS Code Activity Bar. There, Sonar Rules can individually be toggled on or off while running SonarQube for IDE in standalone mode; each rule is clearly marked as on or off, and it’s possible to filter the visible list by an Active, All, and Inactive status.
When your project is bound to SonarQube Server or SonarQube Cloud using Connected mode, the rule set is managed on the server side as defined by the quality profile. See Applying rules while in connected mode, for details.
When a project is bound to a SonarQube (Server, Cloud) or SonarQube Community Build, the RULES view is not visible in the UI. In this case, the rules configuration from the server applies. For more information, see the server documentation about quality profiles to edit rules:
Managing quality profiles in SonarQube Cloud
Managing quality profiles in SonarQube Server
Edit rules
To edit a rule in SonarQube for VS Code, navigate to the SONARQUBE SETUP > RULES view and select the rule you want to edit. Select or deselect any rule in the list to enable or disable it. If a rule has options, you’ll see them at the bottom of the rule description.
Navigate to the SONARQUBE SETUP > RULES view.
Select any rule to open the rule description. Use the filter if desired, or under the three-dots there’s an option to select Find Rule By Key.
Look for Parameters at the bottom of the rule description. In the screenshot below, giraffes are added to the list of at-rules to ignore in rule css:S4662. When edited, the parameters will show both the Current value and the Default value.
To edit a rule, navigate to Settings… > Extensions > SonarLint > User menu, search for
Sonarlint: rules, and select the Edit in settings.json link to open. The code sample provided in the User settings shows two examples: to turn rule javascript:S1481 “off”, and to edit the maximum line length checked by javascript:S103.
When a project is bound to a SonarQube (Server, Cloud) or SonarQube Community Build, the RULES view is not visible in the UI. In this case, the rules configuration from the server applies. For more information, see the server documentation about quality profiles to edit rules:
Managing quality profiles in SonarQube Cloud
Managing quality profiles in SonarQube Server
Unsupported rules
Some rules are simply too advanced to run locally, in SonarQube for IDE. Because some rules report issues at the project level, apply to the architecture of your code base, or require extensive resources to analyze, they are not included when SonarQube for IDE runs an analysis. Unsupported rule types include architecture, injection vulnerabilities, and some advanced bug detection rules.
However, these advanced issues will be reported in the IDE when you are running in connected mode with SonarQube (Server, Cloud) or SonarQube Community Build. See these links for more information:
Sonar Architecture (Beta) in SonarQube Cloud
Injection vulnerabilities in SonarQube for VS Code
Rules while in Connected Mode
Connected Mode syncs your SonarQube Server or SonarQube Cloud Quality Profile with the local analysis to suppress issues reported in the IDE. Therefore, when running in Connected Mode, SonarQube for VS Code will ignore rule settings that are defined locally. See the Connected mode page for more information about running connected mode and the Benefits it brings when working in teams.
Edit rules in connected mode
If you’re running in Connected mode with SonarQube (Server, Cloud) or SonarQube Community Build, you can share customized active rules with your team because you’ll all be using the same quality profile to share rule sets. Please see the relevant instructions for the server you are connecting to:
Understanding quality profiles in SonarQube Cloud
Understanding quality profiles in SonarQube Server
Understanding quality profiles in SonarQube Community Build
Last updated
Was this helpful?