Investigating issues

SonarLint can help developers by letting them perform local analyses to check their code before pushing it back to the SCM. While running an analysis, SonarLint raises an issue every time a piece of code breaks a coding rule.

Usually, a first analysis is performed as soon as one of the supported files is opened. Then, regular analyses are triggered when the editor content changes and/or when the file is saved. 

This page describes how to find and investigate issues in your IDE.

Defining issues

An Issue is a problem in your code that prevents it from being Clean Code. Issues found in code are linked to Clean Code attributes, and these attributes signify how your code will impact one or more software qualities. Software qualities determine the overall severity of an issue that feeds back into the overall status of your code when implementing a Clean as You Code methodology; please see the SonarQube or SonarCloud documentation for more about Clean as You Code.

Each issue is linked to one Clean Code attribute which is associated with one or more software qualities; each software quality has a level of severity. Please check the Clean Code benefits page on software qualities for more information.

To communicate the code attributes, software qualities, and severity of issues found in your code, SonarLint displays them in the Sonar Rule Help view as described below.

Finding issues

For most issues, SonarLint provides information about why there is an issue and offers one or more actions to Fix your issue. Information is displayed in 2 places:

1. In the Visual Studio Text Editor, identifiable by the classic squiggles underlining issues in the code.
2. In the Errors List tool window.

Security hotspots are found in the Local Security Hotspots tool window. Check the Security hotspots page for more details because the window will not appear until a hotspot is found.

Injection vulnerabilities work differently and will appear in the SonarLint Taint Vulnerabilities tool window next to the Error List. See the Injection vulnerabilities page for more details.

Opening issues in the IDE

Understanding issues in context is a helpful way to address problems more effectively. Beginning in SonarQube 10.3 and on SonarCloud, it is possible to open all issues in your IDE, including taint vulnerabilities. Using the Open in IDE feature includes an automated Connected Mode setup to help with the process.

In your instance of SonarQube or on SonarCloud, navigate to your Project > Issues page, pull up an issue’s detail view and select the Open in IDE button as an authenticated user to edit the issue in your IDE. 

It’s best if your project is already open in the appropriate IDE and bound to the server using Connected mode; if not, you will be prompted to set up a new connection and/or bind your project using the automatic Connected Mode setup feature. 

If you’ve already fixed the issue in your code, SonarLint will not be able to find it; only the matching code will be highlighted. In this case, check that recent changes have been analyzed by SonarQube or SonarCloud, then check the documentation on the SonarQube or SonarCloud Issues page for details about managing your issues on the server.

Please see the Connected Mode documentation to bind your project to an instance of SonarQube or SonarCloud. And if you have troubles with the automatic Connected Mode setup, we identified the most common errors for Troubleshooting Connected Mode setup.

Viewing AI-generated fix suggestions in the IDE

SonarQube and SonarCloud can create AI-generated fix suggestions for issues detected in your code. You can view the suggestions directly in your IDE by clicking View Fix in IDE from the Issues page in SonarQube or SonarCloud. 

The process is similar to clicking the Open in IDE button: it’s best to set up connected mode beforehand. Otherwise, you’ll be prompted to set up a new connection and/or bind your project using the automatic Connected Mode setup feature. 

In SonarLint for Visual Studio, clicking View Fix in IDE will directly paste the fix suggestion into your IDE.

SonarLint tool windows

SonarLint Issue Visualization tool window

By default, the tool window will only be visible in the following cases:

• When an injection vulnerability is selected in the SonarLint Taint Vulnerabilities. Check the injection vulnerabilities documentation for complete details.
• When a Hotspot containing secondary locations is selected in the SonarLint Security Hotspots list. Check the Security hotspots documentation for complete details.
• When an issue with secondary locations is selected in the Error List; for example, the window will automatically appear and disappear as the Error List selection changes.
• When the lightbulb suggested action, "SonarLint: show issue visualization," is invoked. The proposed action will appear when hovering over an issue with secondary locations in the Editor as shown in the following screenshot:

Manually re-opening SonarLint Issue Visualization tool window

If you manually close the tool window it will no longer appear and disappear automatically. You can show the window again using one of three menu commands:

• The menu command View, Other Windows, SonarLint Issue Visualization, which is always visible
• The lightbulb suggested action SonarLint: show issue visualization when hovering over an issue in the Editor (see screenshot above)
• The Show SonarLint Issue Visualization command on the Error List context menu, which is available for issues with secondary locations as shown in the following screenshot:

Sonar Rule Descriptions

From SonarLint for Visual Studio v6.14+, users are able to visualize descriptive and educational content associated with each issue. Simply select the issue’s rule as shown below to open the Sonar Rule Help view to view the rule descriptions.

The Sonar 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 are able to 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 Sonar Rule Help view. Below the rule title, you will find the Clean Code issue badges that highlight an issue’s Clean Code classification. 

Check the Clean Code definition page for details about Clean Code attributes, and the Clean Code benefits page to better understand software qualities for more details about how they help classify your issue. 

Be sure to check out the Clean Code definition page for more details about Clean Code attributes and how they help classify your issue. 

Issues with secondary locations

Feature requirements

• SonarLint version 4.26 or higher.
• Supported languages for in-IDE analysis: C, C++, JavaScript, TypeScript
• Supported languages for Security Hotspots and Injection Vulnerabilities: C, C++, C#, VB.NET

Feature Overview

All SonarLint issues specify a location in the code showing where the issue occurs. However, some of the more complex rules produce issues for which a single location is not enough to adequately explain why the issue has occurred. These more complex rules often identify additional locations in the code to help understand the problem. These additional locations are referred to as secondary locations.

For some rules (i.e. cpp:S3529) the secondary locations identify a ‘flow’ through the code that leads to the issue. For other rules (i.e. cpp:S1871), the secondary locations indicate other locations that are related to the issue.

SonarLint for Visual Studio shows these secondary locations in the editor and in a separate tool window.

Navigating between secondary locations

Selecting a secondary location in the tool window will move the edit cursor to the specified location in the code.

It is also possible to navigate between secondary locations using the keyboard with the following shortcuts:

• Go to next location: Ctrl+Shift+Alt+Q, Ctrl+Shift+Alt+Right Arrow
• Go to previous location: Ctrl+Shift+Alt+Q, Ctrl+Shift+Alt+Left Arrow

These shortcut key combinations were chosen to avoid conflicts with existing Visual Studio shortcuts and shortcuts in popular third-party extensions. As always, it is possible to customize these shortcuts in Visual Studio. See the MS documentation for more information.

Non-navigable locations

It is not always possible to navigate to a location in the code; for example, if the code has been changed since the file was analyzed, or the source file has been deleted, the previous destination may no longer exist. The tool window will show which locations are non-navigable:

Known issues

This is a list of known problems with the SonarLint for Visual Studio UI.

Issue Visualization panel will no longer appear and disappear automatically 

• The panel was likely closed manually and therefore needs to be re-opened manually. See the Manually re-opening SonarLint Issue Visualization tool window section (above) for more information.