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 with 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 SonarLint Rule Description view as described below.

Finding issues

Issues are displayed by SonarLint in 2 places:

• In the Eclipse Text Editor, identifiable by the classic squiggles underlining issues in the code.
• In one of the SonarLint view windows listed below: 
  • SonarLint Bindings: A list of the SonarQube and SonarCloud servers and projects bound to SonarLint. Right-click on items for to reveal management options.
  • SonarLint Issue Locations: This view shows the context around your issue and the different locations that are important to understand the issue.
  • SonarLint On-The-Fly: Here you will find issues found in files you select in the  Package/Project Explorer. If no file is selected, this view will report issues found in the active file. The On-The-Fly list is updated when you open a new file, or save your active file.
  • SonarLint Report: The Report view includes issues found when running an analysis from the Eclipse Project or Package Explorer, including issues found when you analyze more than one file.
  • SonarLint Rule Description: This view provides the rule description for the selected issue, giving context to the issue and often compliant and noncompliant examples of the rule violation.
  • SonarLint Security Hotspots: This view displays security hotspots found on the SonarQube server while running in Connected Mode. This view will open by default when you use the Open in IDE button in SonarQube, from a security hotspot.
    *Note that Security Hotspots found by SonarCloud are not yet available in SonarLint.
  • SonarLint Taint Vulnerabilities: Here you will find taint issues reported by the SonarQube or SonarCloud server when running in Connected Mode.

Double-clicking an issue found in one of the views will jump to the issue in the code editor; the issue will automatically be selected. For most issues, SonarLint offers information about why there is an issue and offers one or more actions to Fix your issue.

To open any views you are missing, navigate to Eclipse File Menu > Window > Show View > Other… > SonarLint > your SonarLint view. 

Opening issues in the IDE from SonarQube

Understanding issues in context is a helpful way to address problems more effectively. Beginning in SonarQube 10.3, it is possible to open all issues in your IDE, including taint vulnerabilities. With SonarQube 10.4, an automated Connected Mode setup feature is available.

Go to the SonarQube > Your Project > Issues page, pull up the 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 matching code will be highlighted. In this case, check that recent changes have been analyzed by SonarQube and check the documentation on SonarQube Issues for details about managing your issues on the server.

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

Focusing on new code

Focusing on new code is an important part of the Clean as You Code approach, where you apply your effort and attention to submit clean code and avoid introducing new issues. SonarLint for Eclipse allows you to focus on new code by filtering the issues shown in the IDE, as determined by your SonarQube or SonarCloud new code definition.

Setting your focus on new code has these prerequisites:

• SonarLint must be running in Connected Mode.
• Your local project must be bound to a SonarQube or SonarCloud project.
• The new code definition must be defined in SonarQube or SonarCloud using a Previous version, Number of days, or Specific analysis. 
• The Reference branch new code definition is not supported. Please check the documentation in SonarQube or on SonarCloud to properly set your new code definition. 

Setting the focus on new code is easy. To show or hide issues found in your Overall code, go to Eclipse Window > Preferences > SonarLint (or Eclipse > Settings… > SonarLint for Mac OS) and change SonarLint markers shown: between New code and Overall code.

By default, the SonarLint markers shown are set to New code when you set up a new connection and establish the project binding. 

When switching between modes, settings are applied globally to all projects open in your Eclipse workspace.

The SonarLint views

The On The Fly view

The On-The-Fly view displays issues found in the active file; this list is updated when you open a file or save your active file. Double-click an issue to jump to its line in the Eclipse code editor. Hovering over issues in the code editor will reveal a tooltip that reveals one or more Quick fixes. 

The Report view

The Report view includes issues found when running an analysis from the Eclipse Project or Package Explorer. Right-click on a selection of one or more files or folders in either the Package or Project Explorer, and choose SonarLint > Analyze to populate this view. Unlike the On-The-Fly view, the Report view does not update when you save a file, but the classic squiggles will appear under issues found in the code editor. 

When running an analysis on multiple files or projects, the SonarLint Report view will open automatically and present the issues found in your selection. Note that you can also select Analyze All Project Files from the Report tab, without having to select all project files from the Project Explorer.

The Issue Locations view

For example, if a single issue has multiple locations or is part of a taint vulnerability flow, it will appear in the SonarLint Issue Locations view. For issues with multiple locations, a count of additional locations will be appended to the issue description found in any SonarLint view. 

Taint vulnerabilities are displayed a bit differently in the code editor and SonarLint views to better illustrate the flow of information from sources (user-controlled inputs) to sinks (sensitive functions). The SonarLint Taint Vulnerabilities view will list the vulnerabilities by occurrence, and the Issue Locations view will sequentially report the data flow. Selecting a flow item from the Issue Locations view will highlight the corresponding instance in the Eclipse code editor.

When running SonarLint in Connected Mode, locations are displayed similarly in SonarLint as they are in SonarQube and SonarCloud. Selecting the issue in either the Eclipse code editor or the Issue locations view will highlight the reverse to help you understand the problem in context. Below you can see the similarities between SonarQube (left) and SonarLint for Eclipse (right).

If you don’t see the data flow displayed in the code editor for taint issues, check that code minings are enabled in the Preferences > Java > Editor > Code Minings menu.

Please have a look at the SonarLint documentation on Security hotspots and Taint vulnerabilities for more details about working with each issue type in SonarLint.

The Rule Description view

The SonarLint Rule Descriptions view is usually your first step in identifying why you have an issue. Right-clicking on any issue in a SonarLint view, or exposing the tooltip and selecting Open description of rule… in the code editor will open the SonarLint Rule Descriptions view.

The Rule Descriptions include information about why this causes an issue and noncompliant/compliant code snippets are usually offered. More serious issues such as security hotspots and taint vulnerabilities often include information about why it’s an issue and what is the potential impact.

SonarLint for Eclipse supports syntax highlighting; its availability is dependent on the Eclipse version and plugins you have installed; note that JDT is required for Java syntax highlighting. Currently, syntax highlighting for Java and C / C++ languages are available.

Syntax highlighting is not available for languages accessed with external plugins, but an extension point is provided to plugin developers. More information on extension points will be coming soon...

Understanding issues in your IDE

An issue’s Clean Code attribute, software qualities, and severity are presented to you when opening the SonarLint Rule Description 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. 

Issue types

Eclipse supports having multiple projects open in the same workspace and you may notice changes in the issue badges when switching between projects. The legacy issue types will be displayed when running SonarLint for Eclipse version 8.0+ in Connected Mode with SonarQube versions 10.1 and earlier. This is because previous versions of SonarQube including the 9.9 LTS were released with information from the previous system.

These factors define which classification system is presented for each configuration:

• SonarLint for Eclipse 8.0+ running without Connected Mode will present an issue’s Clean Code attribute.
• SonarLint for Eclipse 8.0+ running in Connected Mode with SonarQube 10.2+ or SonarCloud will present an issue’s Clean Code attribute.
• SonarLint for Eclipse 8.0+ running in Connected Mode with SonarQube 10.1 or earlier will present the legacy issue types. 
  • In this scenario, please refer to the appropriate SonarQube documentation version for your issue types’ description. Here are the two most commonly accessed documentation versions:
    • The Issue page in SonarQube 10.1
    • The Issue page in SonarQube 9.9LTS

Check out the Clean Code definition page for more information about the Clean Code attributes classification system.

Grouping issues

To group issues in the SonarLint SonarLint On-The-Fly, Report, or Taint Vulnerability views, select the 3-dots menu in the upper-right corner of the view and select Group by, then choose the group method.

In SonarLint for Eclipse 8.0+, the two group methods available are Impact and Severity (Legacy), which refer to the issue badge types. Because Eclipse does not allow groupings based on state (for example, if connected to SonarCloud, then...), you must manually select the group that corresponds with your Connected Mode status.

It is important that you select Severity (Legacy) or None when connected to older versions of SonarQube or to SonarCloud. Both group methods work when not running in Connected Mode.