Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Table of Contents



It is the cyclomatic complexity, also known as McCabe metric. Whenever the control flow of a method splits, the complexity counter gets incremented by one.
Each method has a minimum value of 1 per default (except accessors which are not considered as method and so do not increment the complexity).

 More details...
LanguageKeywords incrementing the complexity

Note that else, default, and finally do not increment the complexity. On the other hand, a simple method with a switch statement and a huge block of case statements can have a surprisingly high complexity value (still it has the same value when converting a switch block to an equivalent sequence of if statements).

Example: the following method has a complexity of 5

Complexity /classclass_complexityAverage complexity by class.
Complexity /filefile_complexityAverage complexity by file.
Complexity /methodfunction_complexityAverage complexity by method.



Afferent couplings


A class afferent couplings is a measure of how many other classes use the specific class.

Depth in Tree


The depth of inheritance tree (DIT) metric provides for each class a measure of the inheritance levels from the object hierarchy top.

 More details...
JavaAs every class inherits from Object, the minimum value of DIT is 1.

Efferent couplings


A class efferent couplings is a measure of how many different classes are used by the specific class.

File cycles


Minimal number of file cycles detected inside a package to be able to identify all undesired dependencies.

File edges weight


Number of file dependencies inside a package.

File dependencies to cut


Number of file dependencies to cut in order to remove all cycles between packages.

File tangle


file_tangles = file_feedback_edges.

File tangle index


File tangle index = 2 * (file_tangles / file_edges_weight) * 100.




Lack of cohesion of methods. See LCOM4 documentation page.

Number of children


The number of children of a class is the number of direct and indirect descendants of this class.

Package cycles


Minimal number of package cycles detected to be able to identify all undesired dependencies.

Package dependencies to cut


Number of package dependencies to cut in order to remove all cycles between packages.

Package tangle index


Level of tangle of the packages. Best value (0%) means that there is no cycle and worst value (100%) means that packages are really tangled. This metric is computed with the following formula: 2 * (File dependencies to cut / Number of file dependencies between packages) * 100.

Response for class


See RFC documentation page.

Package edges weight


Total number of file dependencies between packages.

Suspect file dependencies


File dependencies to cut in order to remove cycles between files inside a package. Note that cycles between files inside a package does not always mean a bad quality architecture.

Suspect LCOM4 density Density of files having a LCOM4 density greater than 1.


Blank comments Number of non-significant comments lines (empty comment line, comment line containing only special characters, etc.).
Comment linescomment_lines

Number of javadoc, multi-comment and single-comment lines. Empty comment lines like, header file comments (mainly used to define the license) and commented-out lines of code are not included.

Comments (%)comment_lines_density

Density of comment lines = Number of Comment lines / (Number of Lines of code + Number of Comment lines) * 100

With such a formula:

  • 50% means that the number of lines of code equals the number of comment lines
  • 100% means that the file only contains comment lines
Public documented API (%)public_documented_api_densityDensity of public documented API = (Public API - Public undocumented API) / Public API * 100
Public undocumented APIpublic_undocumented_apiPublic API without comments header.



Duplicated blocks


Number of duplicated blocks of lines.

Duplicated filesduplicated_filesNumber of files involved in a duplication.
Duplicated linesduplicated_linesNumber of lines involved in a duplication.
Duplicated lines (%)duplicated_lines_density

Density of duplication = duplicated_lines / lines * 100



Active reviews


Number of active reviews (status not closed).

False-positive reviews Number fo false-positive reviews.
New unreviewed violations Number of new unreviewed violations.
Unassigned reviews Number of unassigned reviews.
Unplanned reviews Number of unplanned reviews (not associated with an action plan).
Unreviewed violations Number of unreviewed violations.



New violations


Number of new violations.

New xxxxx violations


Number of new violations with severity xxxxx, xxxxx being Blocker, Critical, Major, Minor or Info.



Number of violations.

xxxxx violations


Number of violations with severity xxxxx, xxxxx being Blocker, Critical, Major, Minor or Info.

Weighted violations


Sum of the violations weighted by the coefficient associated to each severity (Sum(xxxxx_violations * xxxxx_weight)).
To set the weight of each severity, log in as an administrator, go to Settings > Configuration > General Settings > General and set the Rules weight property.

Rules compliance


Rules compliance index (RCI) = 100 - (weighted_violations / nloc * 100)


Authors by lineauthors_by_linenoThe last committer on each line of code.

This metric is made available by the SCM Activity plugin.


Blocker Remediation Cost Remediation cost (in days) to fix all blocker violations.




Critical and over Remediation Cost Remediation cost (in days) to fix all critical and blocker violations.
Effort to grade X Effort (in days) to reach grade X.
Major and over Remediation Cost Remediation cost (in days) to fix all major and critical and blocker violations.
Minor and over Remediation Cost Remediation cost (in days) to fix all minor and major and critical and blocker violations.
SQALE Remediation Cost Remediation cost (in days) to fix all violations.

Note that these metrics are made available by the SQALE plugin.



Number of getter and setter methods used to get (reading) or set (writing) a class property.

ClassesclassesNumber of classes (including nested classes, interfaces, enums and annotations).
DirectoriesdirectoriesNumber of directories.
FilesfilesNumber of files.
Generated Lines Number of generated lines (Cobol only).
Generated lines of code Number of generated lines of code (Cobol only).
LineslinesNumber of physical lines (number of carriage returns).
Lines of codenclocNumber of physical lines that contain at least one character which is neither a whitespace or a tabulation or part of a comment.

Number of methods.
Number of paragraphs for Cobol. 

Notes for Java:

  • Accessors are considered as methods if the sonar.squid is set to false
  • Constructors are considered as methods
PackagespackagesNumber of packages.
ProjectsprojectsNumber of projects in a view.
Public APIpublic_apiNumber of public Classes + number of public Methods + number of public Properties (without public final static ones).



Number of statements as defined in the Java Language Specification but without block definitions. Statements counter gets incremented by one each time a following keyword is encountered: if, else, while, do, for, switch, break, continue, return, throw, synchronized, catch, finally.

Statements counter is not incremented by a class, method, field, annotation definition, package declaration and import declaration.


Branch coveragebranch_coverage

On each line of code containing some boolean expressions, the branch coverage simply answers the following question: 'Has each boolean expression been evaluated both to true and false?'. This is the density of possible branches in flow control structures that have been followed during unit tests execution.


It is a mix of Line coverage and Branch coverage. Its goal is to provide an even more accurate answer to the following question: 'How much of the source code has been covered by the unit tests?".

Line coverageline_coverage

On a given line of code, Line coverage simply answers the following 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:

Lines to coverlines_to_coverNumber of lines of code which could be covered by unit tests (for example, blank lines or full comments lines are not considered as lines to cover).
New branch coveragenew_branch_coverageIdentical to Branch coverage but restricted to new / updated source code.
New coveragenew_coverageIdentical to Coverage but restricted to new / updated source code.
New line coveragenew_line_coverageIdentical to Line coverage but restricted to new / updated source code.
New lines to covernew_lines_to_coverIdentical to Lines to cover but restricted to new / updated source code.
New uncovered linesnew_uncovered_linesIdentical to Uncovered lines but restricted to new / updated source code.
Skipped unit testsskipped_testsNumber of skipped unit tests.
Uncovered branchesuncovered_branchesNumber of branches which are not covered by unit tests.
Uncovered linesuncovered_linesNumber of lines of code which are not covered by unit tests.
Unit teststestsNumber of unit tests.
Unit tests durationtest_execution_timeTime required to execute all the unit tests.
Unit test errorstest_errorsNumber of unit tests that have failed.
Unit test failurestest_failuresNumber of unit tests that have failed with an unexpected exception.
Unit test success density (%)test_success_densityTest success density = (tests - (test_errors + test_failures)) / tests * 100

The same kinds of metrics exist for Integration tests coverage and Overall tests coverage (Units tests + Integration tests).

Metrics on tests execution does not exist for Integration tests and Overall tests.

  • No labels