Understanding measures and metrics
This section describes the metrics used in the Sonar solution to evaluate your code.
Metrics are used to measure:
Security, maintainability, and reliability attributes on the basis of statistics on the detected security, maintainability, and reliability issues, respectively.
Test coverage on the basis of coverage statistics on executable lines and evaluated conditions.
Code cyclomatic and cognitive complexities.
Security review level on the basis of statistics on reviewed security hotspots.
Metrics also include statistics on:
Duplicated lines and blocks.
Code size (the number of various code elements).
Issues.
Finally, metrics also include the quality gate status result.
A metric refers to either new code or overall code. Most metrics can be used to define the quality gate conditions.
You can find these metrics in the Measures tab of your projects and portfolios.

You can retrieve the metrics via the Web API by using the metric key.
Security
A list of security metrics used in the Sonar solution. See the Security-related rules page for more details.
Vulnerabilities
vulnerabilities
The total number of security issues (also called vulnerabilities).
Vulnerabilities on new code
new_vulnerabilities
The total number of vulnerabilities raised for the first time on new code.
Security rating
security_rating
Rating related to security. The rating grid is as follows: A = 0 vulnerability B = at least one minor vulnerability C = at least one major vulnerability D = at least one critical vulnerability E = at least one blocker vulnerability
Security rating on new code
new_security_rating
Rating related to security on new code.
Security remediation effort
security_remediation_effort
The effort to fix all vulnerabilities. The remediation cost of an issue is taken over from the effort (in minutes) assigned to the rule that raised the issue (see Technical debt in the Maintainability section).
An 8-hour day is assumed when values are shown in days.
Security remediation effort on new code
new_security_remediation_effort
The same as Security remediation effort but on new code.
Reliability
A list of Reliability metrics used in the Sonar solution.
Bugs
bugs
The total number of issues impacting reliability (reliability issues).
Bugs on new code
new_bugs
The total number of reliability issues raised for the first time on new code.
Reliability rating
reliability_rating
Rating related to reliability. The rating grid is as follows:
A = 0 bug
B = at least one minor bug
C = at least one major bug
D = at least one critical bug
E = at least one blocker bug
Reliability rating on new code
new_reliability_rating
Rating related to reliability on new code.
Reliability remediation effort
reliability_remediation_effort
The effort to fix all reliability issues. The remediation cost of an issue is taken over from the effort (in minutes) assigned to the rule that raised the issue. An 8-hour day is assumed when values are shown in days.
Reliability remediation effort on new code
new_reliability_remmediation_effort
The same as Reliability remediation effort but on new code.
Maintainability
A list of Maintainability metrics used in the Sonar solution.
Code smells
code_smells
The total number of issues impacting the maintainability (maintainability issues).
Code smells on new code
new_code_smells
The total number of maintainability issues raised for the first time on new code.
Technical debt
sqale_index
A measure of effort to fix all maintainability issues.
Technical debt on new code
new_technical_debt
A measure of effort to fix the maintainability issues raised for the first time on new code.
Technical debt ratio
sqale_debt_ratio
The ratio between the cost to develop the software and the cost to fix it.
Technical debt ratio on new code
new_sqale_debt_ratio
The ratio between the cost to develop the code changed on new code and the cost of the issues linked to it.
Maintainability rating
sqale_rating
The rating related to the value of the technical debt ratio.
Maintainability rating on new code
new_squale _rating
The rating related to the value of the technical debt ratio on new code.
Security review
A list of security review metrics used in the Sonar solution. See Security hotspots for more details.
Security hotspots
security_hotspots
The number of security hotspots.
Security hotspots on new code
new_security_hotspots
The number of security hotspots on new code.
Security hotspots reviewed
security_hotspots_reviewed
The percentage of reviewed security hotspots compared in relation to the total number of security hotspots.
New security hotspots reviewed
new_security_hotspots_reviewed
The percentage of reviewed security hotspots on new code.
Security review rating
security_review_rating
The security review rating is a letter grade based on the percentage of reviewed security hotspots. Note that security hotspots are considered reviewed if they are marked as Acknowledged, Fixed, or Safe.
The rating grid is as follows: A = >= 80% B = >= 70% and <80% C = >= 50% and <70% D = >= 30% and <50% E = < 30%
Security review rating on new code
new_security_review_rating
The security review rating for new code.
Coverage
A list of coverage metrics used in the Sonar solution. See the Overview page on test coverage, for more details.
Coverage
coverage
A mix of line coverage and condition coverage. Its goal is to provide an even more accurate answer to the question:
How much of the source code has been covered by unit tests?
coverage = (CT + LC)/(B + EL)
where:
CT: conditions that have been evaluated to true at least once
LC: covered lines = lines_to_cover - uncovered_lines
B: total number of conditions
EL: total number of executable lines (lines_to_cover)
Coverage on new code
new_coverage
This definition is identical to coverage but is restricted to new or updated source code.
Lines to cover
lines_to_cover
Coverable lines. The number of lines of code that could be covered by unit tests, for example, blank lines or full comments lines are not considered as lines to cover. Note that this metric is about what is possible, not what is left to do - that’s uncovered lines.
Lines to cover on new code
new_lines_to_cover
This definition is identical to lines to cover but restricted to new or updated source code.
Uncovered lines
uncovered_lines
The number of lines of code that are not covered by unit tests.
Uncovered lines on new code
new_uncovered_lines
This definition is identical to uncovered lines but restricted to new or updated source code.
Line coverage
line_coverage
On a given line of code, line coverage simply answers the question:
Has this line of code been executed during the execution of the unit tests?
It is the density of covered lines by unit tests:
line_coverage = LC / EL
where:
LC = covered lines = lines_to_cover - uncovered_lines
EL = total number of executable lines (lines_to_cover)
Line coverage on new code
new_line_coverage
This definition is identical to line coverage but restricted to new or updated source code.
Line coverage hits
coverage_line_hist_data
A list of covered lines.
Condition coverage
branch_coverage
The condition coverage answers the following question on each line of code containing boolean expressions:
Has each boolean expression been evaluated both to true
and to false
?
This is the density of possible conditions in flow control structures that have been followed during unit tests execution.
branch_coverage = (CT + CF) / (2*B)
where:
CT = conditions that have been evaluated to true at least once
CF = conditions that have been evaluated to false at least once
B = total number of conditions
Condition coverage on new code
new_branch_coverage
This definition is identical to condition coverage but is restricted to new or updated source code.
Condition coverage hits
branch_coverage_hits_data
A list of covered conditions.
Conditions by line
conditions_by_line
The number of conditions by line.
Covered conditions by line
covered_conditions_by_line
Number of covered conditions by line.
Uncovered conditions
uncovered_conditions
The number of conditions that are not covered by unit tests.
Uncovered conditions on new code
new_uncovered_conditions
This definition is identical to Uncovered conditions but restricted to new or updated source code.
Unit tests
tests
The number of unit tests.
Unit test errors
test_errors
The number of unit tests that have failed.
Unit test failures
test_failures
The number of unit tests that have failed with an unexpected exception.
Skipped unit tests
skipped_tests
The number of skipped unit tests.
Unit tests duration
test_execution_time
The time required to execute all the unit tests.
Unit test success density (%)
test_success_density
test_success_density
= (tests
- (test_errors
+ test_failures
)) / (tests
) * 100
Duplications
A list of duplication metrics used in the Sonar solution.
Duplicated lines density (%)
duplicated_lines_density
Duplicated lines density is calculated by using the following formula:
duplicated_lines_density= duplicated_lines / lines * 100
Duplicated lines density (%) on new code
new_duplicated_lines_density
The same as duplicated lines density but on new code.
Duplicated lines
duplicated_lines
The number of lines involved in duplications.
Duplicated lines on new code
new_duplicated_lines
The number of lines involved in duplications on new code.
Duplicated blocks
duplicated_blocks
The number of duplicated blocks of lines.
For a block of code to be considered as duplicated, for Non-Java projects:
There should be at least 100 successive and duplicated tokens.
Those tokens should be spread at least on:
30 lines of code for COBOL
20 lines of code for ABAP
10 lines of code for other languages
for Java projects:
There should be at least 10 successive and duplicated statements whatever the number of tokens and lines.
Differences in indentation and in string literals are ignored while detecting duplications.
Duplicated block on new code
new_duplicated_blocks
The number of duplicated blocks of lines on new code.
Duplicated files
duplicated_files
The number of files involved in duplications.
Size
A list of size metrics used in the Sonar solution.
New lines
new_lines
The number of physical lines on new code (number of carriage returns).
Lines of code
ncloc
The number of physical lines that contain at least one character which is neither a whitespace nor a tabulation nor part of a comment.
Lines
lines
The number of physical lines (number of carriage returns).
Statements
statements
The number of statements.
Functions
functions
The number of functions. Depending on the language, a function is defined as either a function, a method, or a paragraph. Language-specific details:
COBOL: It’s the number of paragraphs.
Dart: Any function expression is included, whether it’s the body of a function declaration, of a method, constructor, getter, top-level or nested function, top-level or nested lambda.
Java: Methods in anonymous classes are ignored.
VB.NET: Accessors are not considered to be methods.
Classes
classes
The number of classes (including nested classes, interfaces, enums, annotations, mixins, extensions, and extension types).
Files
files
The number of files.
Comment lines
comment_lines
The number of lines containing either comment or commented-out code. See below for calculation details.
Comments (%)
comment_lines_density
The comment lines density. It is calculated based on the following formula: comment_lines_density=[comment_lines / (lines + comment_lines)] * 100
Examples:
50% means that the number of lines of code equals the number of comment lines.
100% means that the file only contains comment lines.
Lines of code per language
ncloc_language_distribution
The non-commented lines of code distributed by language.
Projects
projects
The number of projects in a portfolio.
Complexity
Complexity metrics used in the Sonar solution.
Cyclomatic complexity
complexity
A quantitative metric used to calculate the number of paths through the code.
Cognitive complexity
cognitive_complexity
A qualification of how hard it is to understand the code’s control flow. See the Cognitive Complexity white paper for a complete description of the mathematical model applied to compute this measure.
Cyclomatic complexity
Cyclomatic complexity is a quantitative metric used to calculate the number of paths through the code. The analyzer calculates the score of this metric for a given function (depending on the language, it may be a function, a method, a subroutine, etc.) by incrementing the function’s cyclomatic complexity counter by one each time the control flow of the function splits resulting in a new conditional branch. Each function has a minimum complexity of 1. The calculation formula is as follows:
Cyclomatic complexity = 1 + number of conditional branches
The calculation of the overall code’s cyclomatic complexity is basically the sum of all complexity scores calculated at the function level. In some languages, the complexity of external functions is additionally taken into account.
Split detection by language.
Issues
A list of issues metrics used in the Sonar solution. See the Issue management solution page for information about how SonarQube Cloud identifies issues and manages its life cycle.
Metric
Metric key
Definition
Issues
violations
The number of issues in all states.
Issues on new code
new_violations
The number of issues raised for the first time on new code.
Accepted issues
accepted_issues
The number of issues marked as Accepted.
Open issues
open_issues
The number of issues in the Openstatus.
Accepted issues on new code
new_accepted_issues
The number of Accepted issues on new code.
False positive issues
false_positive_issues
The number of issues marked as False positive.
Blocker issues (software quality)
software_quality_blocker_issues
Issues with Blocker software quality severity level.
High issues (software quality)
software_quality_high_issues
Issues with High software quality severity level.
Medium issues (software quality)
software_quality_medium_issues
Issues with Medium software quality severity level.
Low issues (software quality)
software_quality_low_issues
Issues with Low software quality severity level.
Info issues (software quality)
software_quality_info_issues
Issues with Info software quality severity level.
Blocker issues (type)
blocker_violations
Issues with Blocker type severity level.
Critical issues (type)
critical_violations
Issues with Critical type severity level.
Major issues (type)
major_violations
Issues with Major type severity level.
Minor issues (type)
minor_violations
Issues with Minor type severity level.
Info issues (type)
info_violations
Issues with Info type severity level.
Severities are tied to the Software qualities (security, reliability, maintainability) and types (vulnerability, bug, code smell) of issues they impact. Quality gate conditions related to severity currently use type severities.
Quality Gates
Quality gates metrics used in the Sonar solution.
Quality gate status
alert_status
The state of the quality gate associated with your project. Possible values are ERROR and OK.
Quality gate details
quality_gate_details
Status (passed or failed) of each condition in the quality gate.
Last updated
Was this helpful?
Comment lines
Non-significant comment lines (empty comment lines, comment lines containing only special characters, etc.) do not increase the number of comment lines.
The following piece of code contains 9 comment lines:
In addition:
For COBOL: Generated lines of code and pre-processing instructions (SKIP1, SKIP2, SKIP3, COPY, EJECT, REPLACE) are not counted as lines of code.
For Java and Dart: File headers are not counted as comment lines (because they usually define the license).