- Active Rule
-
An active rule is an instance of a rule. An active rule may have different attributes than the rule. For example severity and parameters values can be overridden in quality profiles, so that different Sonar Projects can be analyzed for the same rule, but with different behavior/threshold. Active rules are part of the input for sensors.
- Active Sonar Project Branch
-
A Sonar Project Branch that is determined to be the active one in a given configuration scope. The client is responsible for determining what the active branch is based on the current VCS branch and all Sonar Project Branches.
- Binding
-
In Connected Mode, this is the association between a configuration scope and a Sonar project, for a given connection.
- Binding Clue
-
For a configuration scope, this is any element that could help to guess what should be the binding in connected mode. A configuration scope can have multiple binding clues, partial, or even contradictory. They will be processed during binding suggestion computation.
- Configuration Scope
-
Represent an abstract IDE element that can be configured, and possibly bound. Usually a project (Eclipse, IntelliJ), module (IntelliJ), solution (VS, Rider), or workspace folder (VSCode).
- Connected Mode
-
The use of SonarLint associated with a SonarQube server or SonarCloud. More details. See also standalone mode.
- Connection
-
A channel of communication between SonarLint and a particular SonarQube server or SonarCloud. See also connected mode.
- Connection Configuration
-
All attributes that will be used to instantiate and operate a connection. Usually provided by the IDE settings. It includes credentials, endpoint URL, timeouts, proxy…
- Effective Rule Details
-
Rule Definition but taking into account the binding and the finding context. Some attributes can be different from the rule definition.
- Finding
-
Generic concept that includes all things reported by Sonar analyzers: issues, security hotspots, taint vulnerabilities, … With the new Clean Code Taxonomy, security hotspots should disappear, and so everything will be an issue, so this concept might disappear.
- Issue Matching
-
Refer to the process, algorithm or heuristic that we use to reconcile issues reported by an analysis with the issues previously reported and tracked. Important part of issue tracking.
- Issue Tracking
-
This is the process allowing to track issues over time, when the source code changes. Tracked issues have an identity, allowing to attach metadata that will be sticky between consecutive analyses.
- Finding Context
-
When reporting a finding, Sonar analyzers can optionally provide a context key. This context key will be used to adapt the Rule Definition to give more specific remediation guidelines. For example, we can have framework specific context (spring vs struts).
- Local Branch
-
The VCS branch that is currently checked out locally.
- Project Key
-
Unique identifier of a Sonar project in a given SonarQube or SonarCloud instance. Project key can be changed on server side (the server use uuid internally).
- Rule Definition
-
All the attributes defining a rule, as provided by Sonar Analyzer, like key, name, default severity, description, … Some attributes of a rule definition can be overridden at different levels. For example severity and parameter values can be changed in the quality profile. The rule description can also be sensitive to the finding context. See Effective Rule Details.
- Rule
-
A coding standard or practice which should be followed. Sonar analyzers will analyze the user’s code and report findings for each rule. Each Sonar analyzer will contribute a set of rules, identified by a unique rule key. Rules have attached rule definition (name, type, tags, description, default activation…). Rules can also have parameters, with default values. On SonarQube or SonarCloud, users can create quality profiles, that are logical rule sets in which they can decide to activate some rules, and override certain rules metadata (severity, parameters, …). Sonar projects are associated with a quality profile. When analyzing the code of a project, sensors are only interested in enabled rules and the effective parameter values. This is what we call active rules.
- Rule Key
-
Unique identifier of a rule. The format of a rule key is always [rule_repo_key]:[rule_id]. For example:
java:S1423. - Rule Repository
-
A rule repository is a logical grouping of rules. This is not a concept exposed in SonarLint. It is mostly used to differentiate rules of the same language that are assessed by different analyzers or sensors.
- Sensor
-
A Sensor is the Java interface implemented by Sonar analyzers to analyze source files and report findings.
- Sonar Analyzer
-
A component responsible to analyze user’s code, for one or multiple languages.
- Sonar Project
-
A project that exists on the Sonar Server (either SonarQube or SonarCloud). Sonar Projects are identified by a projectKey.
- Smart Notifications
-
A feature that enables the IDE to receive notifications, only available in connected mode with SonarQube or SonarCloud. You receive a smart notification when the quality gate status of an opened project in your IDE changes, or when an analysis raises new issues that you’ve introduced in an opened project.
- Sonar Project Branch
-
A branch that has already been analyzed on a Sonar Project.
- Sonar Server
-
An instance of SonarQube or the SonarCloud service, to which SonarLint can be connected.
- Standalone Mode
-
The use of SonarLint without a SonarQube server or SonarCloud. See also connected mode.