Home

Page Item: Home

SLUG: index

SonarLint

SonarLint is a free and open-source IDE plugin that helps developers find and fix issues in real-time as they code, enhancing productivity and code quality, and reducing technical debt. Supporting over 20 languages and 11 IDEs, SonarLint leverages over 5,000 coding and language-specific rules to instantly highlight bugs, vulnerabilities and code smells, and provides contextual guidance on how to fix them.

Sonar’s IDE extensions are available for IntelliJ (and other JetBrains IDEs), VS Code, Visual Studio, and Eclipse and can analyze up to 25 different languages, and can be installed directly from your IDE's plugin marketplace.

Much like a spellchecker, SonarLint highlights problems in your code using error squiggles, provides quick fixes, and gives you detailed information about issues found in your code.

In Connected Mode, SonarLint becomes part of the full Sonar solution that integrates code analysis throughout your development process from IDE to CI pipeline to DevOps platform, helping to make sure that only Clean Code makes it into your project.

Writing clean code

Writing clean code is essential to maintaining a healthy codebase. We define clean code as code that meets a certain defined standard, i.e. code that is reliable, secure, maintainable, readable, and modular, in addition to having other key attributes. This applies to all code: source code, test code, infrastructure as code, glue code, scripts, and more.

Sonar's Clean as You Code approach eliminates many of the pitfalls that arise from reviewing code at a late stage in the development process. The Clean as You Code approach uses your quality gate to alert/inform you when there’s something to fix or review in your new code (code that has been added or changed), helping you to maintain high standards and focus on code quality.

Developing with Sonar

The Sonar solution performs checks at every stage of the development process:

SonarLint provides immediate feedback in your IDE as you write code so you can find and fix issues before a commit.
Then, SonarQube and SonarCloud analyze your pull requests before you merge them, providing another layer of protection against code issues.
Finally, SonarQube and SonarCloud analyze your code on each build, as part of your CI/CD workflow and together with Sonar Quality Gates, keep code with issues from being released to production.

The Sonar solution helps you incorporate the Clean as You Code methodology, enabling you to focus on submitting new, clean code for production, knowing that your existing code will be improved over time.

Have a look at the types of issues that SonarLint detects and browse a full list of Sonar Rules and Rule Descriptions available for static code analysis.

Learn more

Check out the entire suite of Sonar products: SonarQube, SonarCloud, and SonarLint.

Staying connected

You can get help in our online community.

Languages Overview

Lorum ipsum, lorum ipsum.

Languages

tabbed

Eclipse

PLACE ECLIPSE CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

(for Java, JavaScript, PHP, Python and HTML)

tabbed

IntelliJ

PLACE INTELLIJ CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

Supported languages

SonarLint for IntelliJ provides out of the box support for the following languages:

Java
JavaScript/TypeScript
Kotlin
PHP
Python
Ruby
HTML
XML

More languages can be supported by binding your project to SonarQube or SonarCloud

tabbed

Visual Studio

PLACE VISUAL STUDIO CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

VS SUPPORTS THESE RULES: (for C#, VB.NET, JavaScript, TypeScript, C and C++)

Check the rules to see what SonarLint can do for you:

By default SonarLint runs in standalone mode i.e. completely independent of SonarQube/SonarCloud. Simply open a project containing C#, VB, C++, JS or TS files.

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: by default, VS 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.

collapse

Configuration for C# and VB projects

What configuration does SLVS add to my C#/VB.NET projects when binding to a SonarQube/SonarCloud server?

When binding to SonarQube/SonarCloud, SLVS generates configuration files that are needed for Sonar C# and Sonar VB.NET analyzers. The following configuration files are generated for each language:

a .ruleset file that contains the rules configuration corresponding to the Quality Profile (See the Microsoft documentation for Rule sets)
a SonarLint.xml file which contains the rules parameters for Sonar C# and Sonar VB.NET analyzers.

The configuration files are located under the .sonarlint folder in your solution directory.

Each non-test project under your solution needs to reference all of these files in order to be considered as “correctly bound”. If one of the configuration files is not referenced, the project is considered as unbound and SLVS will prompt you to bind it.

How does SLVS recognize that the configuration files are referenced?

The generated ruleset is specified in the CodeAnalysisRuleSet property e.g.

<PropertyGroup>
  <CodeAnalysisRuleSet>path-to-generated-ruleset.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>

The SonarLint.xml file is referenced as an AdditionalFiles item e.g.

<ItemGroup>
  <AdditionalFiles Include="..\.sonarlint\{language}\SonarLint.xml" />
</ItemGroup>

What happens when SLVS binds my C# / VB.NET projects?

If SLVS recognizes that the project does not reference the generated .ruleset file, SLVS will reference it using the following logic:

If the project has no CodeAnalysisRuleSet properties, SLVS will create one and point to the generated .ruleset file. So your project will look like this:

<PropertyGroup>
  <CodeAnalysisRuleSet>path-to-generated-ruleset.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>

If the project has a CodeAnalysisRuleSet property that points to a .ruleset file that is located under the project’s directory, SLVS will amend that ruleset to reference the generated .ruleset file. So your project’s ruleset file will look like this:

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="My ruleset" Description="test" ToolsVersion="16.0">
  <Include Path="path-to-generated-ruleset.ruleset" Action="Default" />
  ...

If the project has a CodeAnalysisRuleSet property that points to a .ruleset file that is not located under the project’s directory, SLVS will create a new .ruleset file and place it under your project’s directory. The new ruleset file references your previous ruleset and Sonar’s generated .ruleset file. So the new ruleset file will look like this:

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="SonarQube - Sonar way" ToolsVersion="14.0">
  <Include Path="path-to-generated-ruleset.ruleset" Action="Default" />
  <Include Path="path-to-your-other-ruleset.ruleset" Action="Default" />
</RuleSet>

Can I customize how my projects are configured?

Yes. The initial binding described above will correctly configure your projects, but you are free to modify this using the standard capabilities of MSBuild e.g. using a Directory.Build.props file, or putting the references in a common targets file that is included in the appropriate projects.

FYI the SonarLint for Visual Studio solution in this repo uses a Directory.Build.props file (see here). It does not contain any project-level rulesets or settings.

See our documentation on how to configure a reference to project rulesets, and Microsoft’s documentation for customizing your build.

tabbed