Rules and languages
The rules and languages supported by SonarQube for Visual Studio.
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 the Software qualities page for more information about these classifications.
Overview
SonarQube for Visual Studio currently supports the following programming languages:
Supported out of the box: SonarQube for Visual Studio 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.
C rules
C# rules
C++ rules
CSS rules
HTML
JavaScript rules
Secrets detection rules
Text
TypeScript rules
T-SQL
VB.NET rules
The following code analyzers are included with the SonarQube for Visual Studio extension: Sonar C#, Sonar VB.Net, Sonar C-Family for C or C++, and SonarJS.
Supported language versions
SonarQube for Visual Studio provides analysis for several languages. Support for your language may vary depending on the SonarQube for Visual Studio 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 Visual Studio.
There are commercial-level rules available in SonarQube Cloud (all plans) and 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 the Visual Studio IDE, you can refer to the SonarQube for IDE roadmap where we list all of our coming soon and newly released features.
Sonar Rule Descriptions
SonarQube for Visual Studio can access descriptive and educational content associated with each issue. Simply select the issue’s rule, as shown below, to open the SonarQube Rule Help view and view the rule descriptions.
In addition, you can access the detailed rule description directly from an issue in the Error List, using the Show Error help option on the contextual menu.
The SonarQube Rule Help view brings rule descriptions and patch instructions relevant to the library or framework you’re using, directly into the IDE. The rule descriptions include a brief explanation of the rule as well as Noncompliant and Compliant code samples.
Users can 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 SonarQube Rule Help view. Below the rule title, you will find the coding attribute labels 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 Visual Studio 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
Be sure to check out the Investigating issues page for more details about how issues appear in your IDE.
Language-specific requirements
See the Language-specific requirements article on the Requirements page.
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 Visual Studio does not support DBD detection.
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 or SonarQube Cloud following a project analysis.
To browse injection vulnerabilities in SonarQube for Visual Studio, configure Connected mode with your SonarQube Server commercial edition 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 Visual Studio, local detection of Sonar Security Hotspots is enabled if you are using Connected mode with SonarQube Server or SonarQube Cloud.
Please see the SonarQube Server documentation on Security hotspots for more details.
Secrets detection
Starting with v6.4, SonarQube for Visual Studio (known as "SonarLint" in v6.4) detects and report hard-coded cloud secrets as issues.
All types of text files are analyzed, irrespective of the type of content (code, configuration, documentation etc). Analysis is triggered whenever the file is opened or saved.
IDE-only
Secrets detection rules are only run in the IDE.
They do not appear in SonarQube (Server, Cloud) or SonarQube Community Build i.e. they can only be configured locally, and the secrets detection rules will not be run by the various Sonar scanners.
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 rules can be enabled and disabled locally; see Edit rules below, for details. It is not currently possible to suppress individual issues.
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 Rules while in Connected Mode, for details.
When a project is bound to a SonarQube (Server, Cloud) or SonarQube Community Build, the settings.json file is ignored. 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 Visual Studio, navigate to Extensions > SonarQube > Options and select Edit Settings to open the settings.json file located at C:\Users<USER>\AppData\Roaming\SonarLint for Visual Studio. See the settings.json file format and location article below for details.
Requirements and limitations
The settins.json file is only applied while running in standalone mode. Not all rule options, such as changing the severity or customize rule parameters, are supported for all languages. The table below outlines what is supported in which version:
C
4.13
Supported
Supported in v4.13-7.2
Supported
C++
4.13
Supported
Supported in v4.13-7.2
Supported
CSS
8.0
Supported
Not supported
Supported in v8.2 and newer
Secrets detection
6.4
Supported
Not supported
Not applicable
C# and VB.NET
8.16
Supported
Not supported
Supported
In SonarLint for Visual Studio 7.3 and newer, changing the Sonar severity of an issue from the IDE is no longer possible. However, it is possible to Customizing a software quality severity level in SonarQube Server.
Disabling a rule
To disable a rule, either edit the settings.json file as described below or select an instance of the rule in the Error List, right-click on it, and choose the Disable rule command on the context menu:
settings.json file format and location
You can view and change the current rule settings by selecting Edit rules settings from the Extensions > SonarQube > Options window. Selecting Edit setting will open the settings.json file:
The settings.json file records your rule settings and is stored in your user’s roaming profile %APPDATA%\SonarLint for Visual Studio. It applies to all supported versions of Visual Studio. If the machine is domain-joined, then the settings file will be automatically copied to any other machine in the domain that the user logs on to.
See this example as a format sample of your settings.json file. It changes the parameters on a few rules, and at the end, excludes any files matching *Interface.cs plus everything in the org/sonar/* directory.
The format of the rule key in the file is [c|cpp|javascript|typescript]:[rule id]. A list of Sonar rules is available on the Rules page of your SonarQube Server instance or on the Rules page of your SonarQube Cloud organization.
If the settings file does not contain an entry for a rule then the default setting for the rule in the Sonar way quality profile will be used.
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 Rules while in Connected Mode for more information.
When a project is bound to a SonarQube (Server, Cloud) or SonarQube Community Build, the settings.json file is ignored. 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
Toggling rules
When the rule settings are changed (either by using the Disable rule command or by directly editing and saving the settings.json file), SonarQube for Visual Studio will automatically re-analyze all open documents. The SonarQube for Visual Studio Output window tab will present a text output describing the processing that has taken place; see this example:
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 IntelliJ 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
Rule severities
The Sonar rule severity defined by SonarQube (Server, Cloud) or SonarQube Community Build are different than the severities defined by Visual Studio. The mapping from Sonar severities to Visual Studio severities are as follows:
Low
Message
Medium
Warning
High
Warning
If you are using connected mode, the rule severities defined in the quality profile will be used. See the Customizing a software quality severity level article in SonarQube Server page for information about its classification structure.
In SonarLint for Visual Studio 7.3 and newer, changing the Sonar severity of an issue is not possible.
Last updated
Was this helpful?