Start Free
10.6 | User guide | Monitoring code metrics | Metric definitions

Was this page helpful?

Metric definitions

On this page

This section explains the code metrics used in the Sonar solution by category.

Complexity

The table below lists the complexity metrics used in the Sonar solution.

MetricMetric keyDefinition
Cyclomatic complexitycomplexityA quantitative metric used to calculate the number of paths through the code. See below.
Cognitive complexitycognitive_complexityA 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.

Both complexity metrics can be used in a quality gate condition on overall code.

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:

cyclomaticComplexity = 1 + numberOfConditionalBranches

The split detection is explained below by language. 

The calculation of the overall code’s Cyclomatic complexity is basically the sum of all complexity scores calculated at the function level. For some languages, complexity outside functions is taken into account additionally. 

ABAP

The ABAP analyzer calculates the Cyclomatic complexity at function level. It increments the Cyclomatic complexity by one each time it detects one of the following keywords: 

  • AND
  • CATCH
  • DO
  • ELSEIF
  • IF
  • LOOP
  • LOOPAT
  • OR
  • PROVIDE
  • SELECT…ENDSELECT
  • TRY
  • WHEN
  • WHILE
C/C++/Objective-C

The C/C++/Objective-C analyzer calculates the Cyclomatic complexity at function and coroutine levels. It increments the Cyclomatic complexity by one each time it detects: 

  • A control statement such as: if, while, do while, for
  • A switch statement keyword such as: case, default
  • The && and || operators
  • The ? ternary operator 
  • A lambda expression definition
C#

The C# analyzer calculates the Cyclomatic complexity at method and property levels. It increments the Cyclomatic complexity by one each time it detects:

  • one of these function declarations: method, constructor, destructor, property, accessor, operator, or local function declaration.
  • A conditional expression
  • A conditional access
  • A switch case or switch expression arm
  • An and/or pattern
  • One of these statements: do, for, foreach, if, while
  • One of these expressions: ??, ??=, ||, or && 
COBOL

The COBOL analyzer calculates the Cyclomatic complexity at paragraph, section, and program levels. It increments the Cyclomatic complexity by one each time it detects one of these commands (except when they are used in a copybook): 

  • ALSO
  • ALTER
  • AND
  • DEPENDING
  • END_OF_PAGE
  • ENTRY
  • EOP
  • EXCEPTION
  • EXEC CICS HANDLE
  • EXEC CICS LINK
  • EXEC CICS XCTL
  • EXEC CICS RETURN
  • EXIT
  • GOBACK
  • IF
  • INVALID
  • OR
  • OVERFLOW
  • SIZE
  • STOP
  • TIMES
  • UNTIL
  • USE
  • VARYING
  • WHEN
Java

The Java analyzer calculates the Cyclomatic complexity at method level. It increments the Cyclomatic complexity by one each time it detects one of these keywords: 

  • If
  • for
  • while
  • case
  • &&
  • ||
  • ?
  • ->
JS/TS, PHP

The JS/TS analyzer calculates the Cyclomatic complexity at function level. The PHP analyzer calculates the Cyclomatic complexity at function and class levels. Both analyzers increment the Cyclomatic complexity by one each time they detect:

  • A function (i.e non-abstract and non-anonymous constructors, functions, procedures or methods)
  • An if keyword
  • A short-circuit (AKA lazy) logical conjunction (&&)
  • A short-circuit (AKA lazy) logical disjunction (||)
  • A ternary conditional expression
  • A loop
  • A case clause of a switch statement
  • A throw or a catch statement
  • A go to statement (only for PHP)
PL/I

The PL/I analyzer increments the Cyclomatic complexity by one each time it detects one of the following keywords: 

  • PROC
  • PROCEDURE
  • GOTO
  • GO TO
  • DO
  • IF
  • WHEN
  • |
  • !
  • |=
  • !=
  • &
  • &=
  • A DO statement with conditions (Type 1 DO statements are ignored)
PL/SQL

The PL/SQL analyzer calculates the Cyclomatic complexity at function and procedure level. It increments the Cyclomatic complexity by one each time it detects:

  • The main PL/SQL anonymous block (not inner ones)
  • One of the following statements: 
    • CREATE PROCEDURE 
    • CREATE TRIGGER 
    • basic LOOP 
    • WHEN clause (the “WHEN” of simple CASE statement and searched CASE statement)
    • cursor FOR LOOP
    • CONTINUE / EXIT WHEN clause (The “WHEN” part of the CONTINUE and EXIT statements)
    • exception handler (every individual “WHEN”)
    • EXIT 
    • FORLOOP
    • FORALL
    • IF
    • ELSIF
    • RAISE
    • WHILELOOP
  • One of the following expressions:
    • ANDexpression (“AND” reserved word used within PL/SQL expressions)
    • Rexpression (“OR” reserved word used within PL/SQL expressions), 
    • WHEN clause expression (the “WHEN” of simple CASE expression and searched CASE expression)
VB.NET

The VB.NET analyzer calculates the Cyclomatic complexity at function, procedure, and property levels. It increments the Cyclomatic complexity by one each time it detects:

  • a method or constructor declaration (Sub, Function), 
  • AndAlso
  • Case
  • Do
  • End
  • Error
  • Exit
  • For
  • ForEach
  • GoTo
  • If
  • Loop
  • On Error
  • OrElse
  • Resume
  • Stop
  • Throw
  • Try
  • While

Coverage

The table below lists the test coverage metrics used in the Sonar solution.

MetricMetric keyDefinition
Condition coveragebranch_coverage

On each line of code containing some boolean expressions, the condition coverage answers the following question: '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.

conditionCoverage = (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 codenew_branch_coverage This definition is identical to Condition coverage but is restricted to new/updated source code.
Condition coverage hitsbranch_coverage_hits_dataA list of covered conditions.
Conditions by lineconditions_by_lineThe number of conditions by line.
Coveragecoverage

A mix of Line coverage and Condition coverage. It's goal is to provide an even more accurate answer the question  'How much of the source code has been covered by the unit tests?'.

coverage = (CT + CF + LC)/(2*B + EL)

where:

  • CT = conditions that have been evaluated to 'true' at least once
  • CF = conditions that have been evaluated to 'false' at least once
  • LC = covered lines = linesToCover - uncoveredLines
  • B = total number of conditions
  • EL = total number of executable lines (linesToCover)
Coverage on new codenew_coverageThis definition is identical to Coverage but is restricted to new/updated source code.
Line coverageline_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 ( linesToCover  -  uncoveredLines )
  • EL = total number of executable lines (Lines to cover)
Line coverage on new codenew_line_coverageThis definition is identical to Line coverage but restricted to new/updated source code.
Line coverage hitscoverage_line_hist_dataA list of covered lines.
Lines to coverlines_to_coverCoverable 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 codenew_lines_to_coverThis definition is Identical to Lines to cover but restricted to new/updated source code.
Skipped unit testsskipped_testsThe number of skipped unit tests.
Uncovered conditionsuncovered_conditionsThe number of conditions that are not covered by unit tests.
Uncovered conditions on new codenew_uncovered_conditionsThis definition is identical to Uncovered conditions but restricted to new/updated source code.
Uncovered linesuncovered_linesThe number of lines of code that are not covered by unit tests.
Uncovered lines on new codenew_uncovered_linesThis definition is identical to Uncovered lines but restricted to new/updated source code.
Unit teststestsThe number of unit tests.
Unit tests durationtest_execution_timeThe time required to execute all the unit tests.
Unit test errorstest_errorsThe number of unit tests that have failed.
Unit test failurestest_failuresThe number of unit tests that have failed with an unexpected exception.
Unit test success density (%) test_success_densityunitTestSuccessDensity = (unitTests - (unitTestErrors + unitTestFailures)) / (unitTests) * 100

Most of the coverage metrics can be used in a quality gate condition.

Duplication

The table below lists the duplication metrics used in the Sonar solution.

MetricMetric keyDefinition
Duplicated blocksduplicated_blocks

The number of duplicated blocks of lines.

For a block of code to be considered as duplicated:

  • 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
  • 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 files duplicated_filesThe number of files involved in duplications.
Duplicated linesduplicated_linesThe number of lines involved in duplications.
Duplicated lines (%)duplicated_lines_density

Is calculated by using the following formula:

duplicatedLines / numberOfLinesOfCode * 100

The duplication metrics can be used in a quality gate condition.

Issues

The table below lists the issues metrics used in the Sonar solution.

MetricMetric keyDefinition
New issuesnew_violationsThe total number of issues raised for the first time on new code.
IssuesviolationsThe total number of issues in all states.
False positive issuesfalse_positive_issues The total number of issues marked as False positive.
Open issuesopen_issuesThe total number of issues in the Open status.
Accepted issuesaccepted_issuesThe total number of issues marked as Accepted.

All issues metrics can be used in a quality gate condition (on overall code) except New issues.

Maintainability

The table below lists the maintainability metrics used in the Sonar solution.

MetricMetric keyDefinition
Issuescode_smellsThe total number of issues impacting the maintainability (maintainability issues).
New issuesnew_code_smellsThe total number of maintainability issues raised for the first time on new code.
Technical debtsqale_indexA measure of effort to fix all maintainability issues. See below.
Technical debt on new codenew_technical_debtA measure of effort to fix the maintainability issues raised for the first time on new code. See below.
Technical debt ratiosqale_debt_ratioThe ratio between the cost to develop the software and the cost to fix it. See below.
Technical debt ratio on new codenew_sqale_debt_ratioThe ratio between the cost to develop the code changed on new code and the cost of the issues linked to it. See below.
Maintainability ratingsqale_ratingThe rating related to the value of the technical debt ratio. See below.
Maintainability rating on new codenew_squale _ratingThe rating related to the value of the technical debt ratio on new code. See below.

All maintainability metrics can be used in a quality gate condition.

Technical debt

The technical debt is the sum of the maintainability issue remediation costs. An issue remediation cost is the effort (in minutes) evaluated to fix the issue. The issue remediation cost is taken over from the effort assigned to the rule that raised the issue.

An 8-hour day is assumed when the technical debt is shown in days.

Technical debt ratio

The technical debt ratio is the ratio between the cost to develop the software and the technical debt (the cost to fix it). It is calculated based on the following formula:

technicalDebt /(costToDevelop1lineOfCode * numberOfLinesOfCode)

Where the cost to develop one line of code is predefined in the database (by default, 30 minutes, can be changed).

Example:

  • Technical debt: 122,563
  • Number of lines of code: 63,987
  • Cost to develop one line of code: 30 minutes
  • Technical debt ratio: 6.4%
Maintainability rating

The default Maintainability rating grid is:

A=0-0.05, B=0.06-0.1, C=0.11-0.20, D=0.21-0.5, E=0.51-1

The Maintainability rating scale can be alternately stated by saying that if the outstanding remediation cost is:

  • <=5% of the time that has already gone into the application, the rating is A
  • between 6 to 10% the rating is a B
  • between 11 to 20% the rating is a C
  • between 21 to 50% the rating is a D
  • anything over 50% is an E

You can define another maintainability rating grid: see Changing the Maintainability rating grid.

Quality gate

The table below lists the quality gate metrics used in the Sonar solution.

MetricMetric keyDefinition
Quality gate statusalert_status

The state of the quality gate associated with your project. 

Possible values are ERROR and OK. 

Quality gate detailsquality_gate_detailsStatus (failing or not) of each condition in the quality gate.

Reliability

The table below lists the reliability metrics used in the Sonar solution.

MetricMetric keyDefinition
IssuesbugsThe total number of issues impacting the reliability (reliability issues).
New issuesnew_bugsThe total number of reliability issues raised for the first time on new code.
Reliability ratingreliability_ratingRating 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 remediation effortreliability_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 (see Technical debt above). 

An 8-hour day is assumed when values are shown in days.

Reliability remediation effort on new codenew_reliability_remmediation_effortThe same as Reliability remediation effort but on new code.

All reliability metrics below can be used in a quality gate condition.

Security

The table below lists the security metrics used in the Sonar solution.

MetricMetric keyDefinition
IssuesvulnerabilitiesThe total number of issues impacting the security (security issues).
Issues on new codenew_vulnerabilitiesThe total number of security issues raised for the first time on new code.
Security ratingsecurity_ratingRating 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 remediation effortsecurity_remediation_effort

The effort to fix all security issues. 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 above). 

An 8-hour day is assumed when values are shown in days.

Security remediation effort on new codenew_security_remediation_effortThe same as Security remediation effort but on new code.
Security hotspotssecurity_hotspotsThe number of security hotspots.
Security hotspots on new codenew_security_hotspotsThe number of security hotspots on new code.

All security metrics can be used in a quality gate condition except the Security hotspots metrics.

Security review

The table below lists the security review metrics used in the Sonar solution.

MetricMetric keyDefinition
Security hotspots reviewedsecurity_hotspots_reviewedThe percentage of reviewed security hotspots compared in relation to the total number of security hotspots.
New security hotspots reviewednew_security_hotspots_reviewedThe percentage of reviewed security hotspots on new code.
Security review ratingsecurity_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 codenew_security_review_ratingThe security review rating for new code.

All security review metrics can be used in a quality gate condition.

Size

The table below lists the size metrics used in the Sonar solution.

MetricMetric keyDefinition
ClassesclassesThe number of classes (including nested classes, interfaces, enums, and annotations).
Comment linescomment_linesThe 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: 

[commentLines / (NumberOfLinesOfCode + commentLines)] * 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.
DirectoriesdirectoriesThe number of directories.
FilesfilesThe number of files.
LineslinesThe number of physical lines (number of carriage returns).
Lines of codenclocThe number of physical lines that contain at least one character which is neither a whitespace nor a tabulation nor part of a comment.
Lines of code per language ncloc_language_distributionThe non-commented lines of code distributed by language.
Functionsfunctions

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.
  • Java: Methods in anonymous classes are ignored.
  • VB.NET: Accessors are not considered to be methods.
ProjectsprojectsThe number of projects in a portfolio.
StatementsstatementsThe number of statements.
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:

/**                                            +0 => empty comment line
 *                                             +0 => empty comment line
 * This is my documentation                    +1 => significant comment
 * although I don't                            +1 => significant comment
 * have much                                   +1 => significant comment
 * to say                                      +1 => significant comment
 *                                             +0 => empty comment line
 ***************************                   +0 => non-significant comment
 *                                             +0 => empty comment line
 * blabla...                                   +1 => significant comment
 */                                            +0 => empty comment line

/**                                            +0 => empty comment line
 * public String foo() {                       +1 => commented-out code
 *   System.out.println(message);              +1 => commented-out code
 *   return message;                           +1 => commented-out code
 * }                                           +1 => commented-out code
 */                                            +0 => empty comment line

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: File headers are not counted as comment lines (because they usually define the license).

Most of the size metrics can be used in a quality gate condition.

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARLINT, SONARQUBE, SONARCLOUD, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Creative Commons License