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

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.

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

• Fully supported: 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 Visual Studio.

• Languages in SonarQube Server

• Languages in SonarQube Cloud

• Languages in in SonarQube Community Build

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.

In addition, you will benefit from the following code analyzers: Sonar C#, Sonar VB.Net, Sonar C-Family for C or C++, and SonarJS.

For C# and VB.Net, new issues will be reported as you type. You do not have to select Run Code Analysis from the Analyze menu - the rules are run automatically. Note that by default, Visual Studio is configured to only run Roslyn analyzers on files that are currently open. You can choose to have the analysis run on the entire solution as described in the Microsoft docs, although this is obviously more processor-intensive.

For C, C++, JavaScript, and TypeScript, new issues will be reported when you open or save a file. Issues are highlighted in your code, and also listed in the ‘Error List’.

You can access the detailed rule description directly from the issue in the Error List, using the Show Error help option on the contextual menu.

See the page on Connected mode for more details about language support for analyses while connected to SonarQube (Server, Cloud) or SonarQube Community Build.

Rule selection

The rules can be enabled and disabled locally. It is not currently possible to suppress individual issues. If you are using Connected mode with SonarQube (Server, Cloud) or SonarQube Community Build, the rule severities defined in the quality profile will be used.

Language-specific configuration

<!-- Sample Directory.Build.props content -->
<Project>
  <PropertyGroup>
    <CodeAnalysisRuleSet>$(MSBuildThisFileDirectory)Example.ruleset</CodeAnalysisRuleSet>
  </PropertyGroup>
</Project>

<!-- Snippet to conditionally set the ruleset to file that might not exist on all dev machines -->
<PropertyGroup>
  <CodeAnalysisRuleset Condition="Exists('$(LocalAppData)\Example.ruleset')">$(LocalAppData)\Example.ruleset</CodeAnalysisRuleset>
</PropertyGroup>

<?xml version="1.0" encoding="utf-8"?>
<!-- Example props file to drop in %LocalAppData%\Microsoft\MSBuild\[VERSION]\Microsoft.Common.targets\ImportBefore -->
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <CodeAnalysisRuleset Condition="Exists('$(LocalAppData)\Example.ruleset')">$(LocalAppData)\Example.ruleset</CodeAnalysisRuleset>
  </PropertyGroup>
</Project>

Define C, C++, CSS, JS, TS or secrets detection rules for local analysis

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 Editing issues in SonarQube Server.

Enable or disable rule for local analysis

In standalone mode, it is possible to enable or disable rules, configure rule parameters, and in versions 4.13-7.2, change the reported rule severity. Not all options are supported for all languages. See the table below for more information:

Language

From version

Enable/disable

Change severity

Configure rule parameters

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

JavaScript

4.35

Supported

Not supported. See #2399.

Supported in v8.2 and newer

TypeScript

4.35

Supported

Not supported. See #2399.

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

Disabling a rule

To disable a rule, select an instance of the rule in the Error List, right-click on it, and choose the Disable rule command on the context menu:

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:

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:

settings.json file format and location

The settings.json file 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.

Copy

{
 "sonarlint.rules": {
   "c:S1135": {
     "level": "On"
   },
   "cpp:S1199": {
     "level": "Off"
   },
   "cpp:SingleGotoOrBreakPerIteration": {
     "level": "On",
     "parameters": {
       "maxNumberOfTerminationStatements": "1"
     }
   },
   "javascript:S1135": {
     "level": "Off"
   },
   "typescript:S1854": {
     "level": "On"
   }
 }
  "sonarlint.analysisExcludesStandalone": "**/*Interface.cs,org/sonar/*"
}

The format of the rule key in the file is [c|cpp|javascript|typescript]:[rule id]. The full list of rules is available at https://rules.sonarsource.com/.

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.

Note: the settings file is ignored when SonarQube for Visual Studio is running in Connected mode.

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.

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

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 page for more information.

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:

If you are using connected mode, the rule severities defined in the quality profile will be used. See the Editing issues article in SonarQube Server page for information about its classification structure.

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.

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.

Documentation for individual Secrets rules can be found on the Sonar rules website.

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.