-
Notifications
You must be signed in to change notification settings - Fork 82
Languages and rules
The content on this page has moved: https://docs.sonarsource.com/sonarlint/vs-code/using-sonarlint/rules/
The SonarLint documentation has moved! Please visit https://docs.sonarsource.com/sonarlint/vs-code/ to have a look at the new documentation website. We’ve improved the documentation as a whole, integrated the four SonarLint IDE extension docs together, and moved everything under the sonarsource.com domain to share a home with the SonarQube docs (SonarCloud to come in Q3 of 2023).
These GitHub wikis will no longer be updated after September 1st, 2023 but no worries, we’ll keep them around a while for those running previous versions of SonarLint for VS Code.
Out of the box, SonarLint automatically checks your code against the following rules:
- C rules
- C++ rules
- Cloud formation
- CSS rules
- Docker
- Go rules
- HTML rules
- Java rules
- JavaScript rules
- Kubernetes
- Python and IPython notebook rules
- PHP rules
- Secrets rules
- Terraform
- TypeScript rules
In addition, SonarLint for VS Code supports the following analysis when running in Connected Mode.
- Apex rules See below for more details.
- COBOL rules. See also the COBOL Analysis specific requirements below for more information about this feature.
- PL/SQL rules See below for more details.
- Secrets detection See below for more details.
The full list of available rules is visible in the SONARLINT RULES view of the SonarLint view container, where 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.
The SonarLint language server requires a Java Runtime (JRE) 11+.
On the following platforms, SonarLint comes with its own Java runtime:
- Windows x86-64
- Linux x86-64
- macOS x86-64 (Intel Macs) and arm-64 (Apple Silicon Macs)
On other platforms and if a Java runtime is already installed on your computer, SonarLint should automatically find and use it. Here is how SonarLint will search for an installed JRE (in priority order):
-
the
sonarlint.ls.javaHome
variable in VS Code settings if set. For instance:{ "sonarlint.ls.javaHome": "C:\Program Files\Java\jre-11.0.11" }
-
embedded JRE for platform-specific installations
-
the value of the
JDK_HOME
environment variable if set -
the value of the
JAVA_HOME
environment variable if set -
on Windows the registry is queried
-
if a JRE is still not found then:
- the
PATH
is scanned forjavac
- on macOS, the parent directory of
javac
is checked for ajava_home
binary. If that binary exists then it is executed and the result is used - the grandparent directory of
javac
is used. This is similar to$(dirname $(dirname $(readlink $(which javac))))
- the
SonarLint then uses the first JRE found in these steps to check its version.
If a suitable JRE cannot be found at those places, SonarLint will ask for your permission to download and manage its own version.
The support for Apex analysis is only available together with SonarQube Enterprise Edition or SonarCloud when running in Connected Mode. You will also need the Salesforce Extension Pack VS Code extension.
To analyze C and C++ code, SonarLint requires that you define a path to your compile commands.
Search for Path To Compile Commands in the VS Code Settings (or go to VS Code Settings > Extensions > SonarLint > User and scroll to the entry); then enter the full path to your active compilation database:
Note: if you are using Microsoft Visual C++ compiler, the environment should be ready to build the code. For example, by launching VS Code from your Visual Studio Command Prompt.
More information about supported environments and troubleshooting tips can be found on the C and CPP analysis page.
COBOL analysis is a feature available in SonarLint for VS Code v3.19+ only when running in Connected Mode with SonarQube Enterprise edition+ or SonarCloud. In addition, the VS Code Language Mode must be set to COBOL independent of your file type. If your extension doesn’t set the language automatically, please see the VS Code documentation to learn how to manually change the language for the selected file.
By default, SonarLint takes the analysis configuration from the SonarQube or SonarCloud server therefore it is required that your project has already been analyzed by SonarQube or SonarCloud. The following COBOL analyzer properties are synced by default unless previously overridden locally. Note that all properties found on the server will be synced locally, not just this selection:
sonar.cobol.dialect
sonar.cobol.file.suffixes
sonar.cobol.sourceFormat
sonar.cobol.copy.suffixes
sonar.cobol.copy.directories
In case copybooks are in different location locally, the analyzer property sonar.cobol.copy.directories
should be defined in the /project/.vscode/settings.json
file.
If working with COBOL files via Zowe explorer, it is recommended to update your Zowe workspace settings in VS Code by modifying the temporary file location; temporary files should be saved to your project folder which is bound to SonarQube or SonarCloud. With the correct configuration, the analysis will be executed normally and you should see detected problems.
SonarLint for VS Code 3.17+ supports analysis of Infrastructure as Code (IaC) to help you secure your deployments. See the Sonar Rules pages as linked below for complete details:
To enable the support for Java analysis, you need the Language support for Java VSCode extension (version 0.56.0 or higher). You also need to be in standard mode.
To analyze JavaScript and TypeScript code, SonarLint requires Node.js executable. The minimal supported version is 14.17.0
for standalone analysis or in Connected Mode with SonarCloud. For Connected Mode with SonarQube, it depends on the version of the JS/TS analyzer on your SonarQube server. SonarLint will attempt to automatically locate node, or you can force the location using:
{
"sonarlint.pathToNodeExecutable": "/home/yourname/.nvm/versions/node/v14.17.0/bin/node"
}
Analysis of TypeScript in Connected Mode with SonarQube requires the server to use version 8.1 or above.
SonarLint for VS Code v3.16+ supports analysis of Python code inside Jupyter notebooks. See the documentation page for details.
The support for PL/SQL analysis is only available together with SonarQube Developer Edition or SonarCloud when running in Connected Mode. You also need the Oracle Developer Tools for VSCode VS Code extension.
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, establish 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 are available in the SonarQube or SonarCloud documentation.
In SonarLint for VS Code 3.14 and above, local detection of Security Hotspots is enabled if you are using Connected Mode with SonarQube 9.7 or above.
Please see the documentation for more details.
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.
Simply right-click an issue in the PROBLEMS Panel, and choose SonarLint: Open description of rule ...
to open the SonarLint Rule Description Webview. Here you will find a brief explanation of the rule, along with a noncompliant and compliant code example.
For some SonarLint Rule Descriptions, you are able to visualize a diff view for the noncompliant and compliant code sample which should help you fix your issue.