This an an archived version of the documentation for SonarQube version 4.5 & 4.5.x LTS.
See https://docs.sonarqube.org/display/SONAR/Documentation for current functionality
Complexity
Name | Key | Description |
Complexity | complexity | It is the cyclomatic complexity, also known as McCabe metric. Whenever the control flow of a function splits, the complexity counter gets incremented by one. Each function has a minimum complexity of 1. |
Complexity /class | class_complexity | Average complexity by class. |
Complexity /file | file_complexity | Average complexity by file. |
Complexity /method | function_complexity | Average complexity by function. |
Design
Name | Key | Description |
File cycles | file_cycles | Minimal number of file cycles detected inside a directory to be able to identify all undesired dependencies. This metric is available at directory level. |
File edges weight | file_edges_weight | Number of file dependencies inside a directory. This metric is available at directory level. |
File dependencies to cut | package_tangles | Number of file dependencies to cut in order to remove all cycles between directories. This metric is available at directory, module and project level.
|
File tangle | file_tangles | File tangle = Suspect file dependencies This metric is available at directory level. |
File tangle index | file_tangle_index | File tangle index = 2 * (File tangle / File edges weight) * 100. This metric is available at directory level. |
Package cycles | package_cycles | Minimal number of directory cycles detected to be able to identify all undesired dependencies. This metric is available at directory, module and project level. |
Package dependencies to cut | package_feedback_edges | Number of directory dependencies to cut in order to remove all cycles between directories. This metric is available at the package, module and program levels. |
Package tangle index | package_tangle_index | Level of directory interdependency. Best value (0%) means that there is no cycle and worst value (100%) means that directories are really tangled. This metric is computed with the following formula: 2 * (File dependencies to cut / Number of file dependencies between directories) * 100. This metric is available at directory, module and project level. |
Package edges weight | package_edges_weight | Number of file dependencies between directories. This metric is available at directory, module and project level. |
Suspect file dependencies | file_feedback_edges | File dependencies to cut in order to remove cycles between files inside a directory. Note that cycles between files inside a directory does not always mean a bad quality architecture. This metric is available at directory level. |
Documentation
Name | Key | Description |
Comment lines | comment_lines | Number of lines containing either comment or commented-out code. 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 |
Comments (%) | comment_lines_density | Density of comment lines = Comment lines / (Lines of code + Comment lines) * 100 With such a formula:
|
Comments in Procedure Divisions | Comments in Procedure divisions (Cobol only) | |
Public documented API (%) | public_documented_api_density | Density of public documented API = (Public API - Public undocumented API) / Public API * 100 |
Public undocumented API | public_undocumented_api | Public API without comments header. |
Duplications
Name | Key | Description |
Duplicated blocks | duplicated_blocks | Number of duplicated blocks of lines. For a block of code to be considered as duplicated:
Differences in indentation as well as in string literals are ignored while detecting duplications. |
Duplicated files | duplicated_files | Number of files involved in a duplication. |
Duplicated lines | duplicated_lines | Number of lines involved in a duplication. |
Duplicated lines (%) | duplicated_lines_density | Density of duplication = Duplicated lines / Lines * 100 |
Issues
Name | Key | Description |
New issues | new_violations | Number of new issues. |
New xxxxx issues | new_xxxxx_violations | Number of new issues with severity xxxxx, xxxxx being blocker, critical, major, minor or info. |
Issues | violations | Number of issues. |
xxxxx issues | xxxxx_violations | Number of issues with severity xxxxx, xxxxx being blocker, critical, major, minor or info. |
False positive issues | false_positive_issues | Number of false positive issues |
Open issues | open_issues | Number of issues whose status is Open |
Confirmed issues | confirmed_issues | Number of issues whose status is Confirmed |
Reopened issues | reopened_issues | Number of issues whose status is Reopened |
Weighted issues | weighted_violations | Sum of the issues weighted by the coefficient associated to each severity (Sum(xxxxx_violations * xxxxx_weight)). |
Rules compliance | violations_density | Rules compliance index (RCI) = 100 - (Weighted issues / Lines of code * 100) |
Technical debt | sqale_index | Effort to fix all issues. The measure is stored in minutes in the DB. |
Severity
Severity | Description |
---|---|
Blocker | Operational/security risk: This issue might make the whole application unstable in production. Ex: calling garbage collector, not closing a socket, etc. |
Critical | Operational/security risk: This issue might lead to an unexpected behavior in production without impacting the integrity of the whole application. Ex: NullPointerException, badly caught exceptions, lack of unit tests, etc. |
Major | This issue might have a substantial impact on productivity. Ex: too complex methods, package cycles, etc. |
Minor | This issue might have a potential and minor impact on productivity. Ex: naming conventions, Finalizer does nothing but call superclass finalizer, etc. |
Info | Not known or yet well defined security risk or impact on productivity. |
Size
Metric | Key | Description |
---|---|---|
Accessors | accessors | Number of getter and setter functions used to get (reading) or set (writing) a class property. |
Classes | classes | Number of classes (including nested classes, interfaces, enums and annotations). |
Directories | directories | Number of directories. |
Files | files | Number of files. |
Generated Lines | generated_lines | Number of lines generated by Cobol code generators like CA-Telon. |
Generated lines of code | generated_ncloc | Number of lines of code generated by Cobol code generators like CA-Telon. |
Inside Control Flow Statements | cobol_inside_ctrlflow_statements | Number of inside (intra program) control flow statements (GOBACK, STOP RUN, DISPLAY, CONTINUE, EXIT, RETURN, PERFORM paragraph1 THRU paragraph2). Cobol only. |
Lines | lines | Number of physical lines (number of carriage returns). |
Lines of code | ncloc | Number of physical lines that contain at least one character which is neither a whitespace or a tabulation or part of a comment. |
LOCs in Data Divisions | cobol_data_division_ncloc | Number of lines of code in Data divisions. Generated lines of code are excluded. Cobol only. |
LOCs in Procedure Divisions | cobol_procedure_division_ncloc | Number of lines of code in Procedure divisions. Generated lines of code are excluded. Cobol only. |
Methods | functions | Number of functions. Depending on the language, a function is either a function or a method or a paragraph. |
Outside Control Flow Statements | cobol_outside_ctrlflow_statements | Number of outside (inter programs) control flow statements (CALL, EXEC CICS LINK, EXEC CICS XCTL, EXEC SQL, EXEC CICS RETURN). Cobol only. |
Projects | projects | Number of projects in a view. |
Public API | public_api | Number of public Classes + number of public Functions + number of public Properties |
Statements | statements | Number of statements. |
Tests
Metric | Key | Description |
---|---|---|
Condition coverage | branch_coverage | On each line of code containing some boolean expressions, the condition coverage simply answers the following question: 'Has each boolean expression been evaluated both to true and false?'. This is the density of possible conditions in flow control structures that have been followed during unit tests execution. Condition 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 | Identical to Condition coverage but restricted to new / updated source code. To be computed this metric requires the SCM Activity plugin. |
Condition coverage hits | branch_coverage_hits_data | List of covered conditions. |
Condition coverage | see Condition coverage | |
Conditions by line | conditions_by_line | Number of conditions by line. |
Covered conditions by line | covered_conditions_by_line | Number of covered conditions by line. |
Coverage | coverage | It is a mix of Line coverage and Condition 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? 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 = 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 | Identical to Coverage but restricted to new / updated source code. To be computed this metric requires the SCM Activity plugin . |
Line coverage | line_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: 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 | Identical to Line coverage but restricted to new / updated source code. |
Line coverage hits | coverage_line_hits_data | List of covered lines. |
Lines to cover | lines_to_cover | Number 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). |
Lines to cover on new code | new_lines_to_cover | Identical to Lines to cover but restricted to new / updated source code. |
Skipped unit tests | skipped_tests | Number of skipped unit tests. |
Uncovered conditions | uncovered_conditions | Number of conditions which are not covered by unit tests. |
Uncovered conditions on new code | new_uncovered_conditions | Identical to Uncovered conditions but restricted to new / updated source code. |
Uncovered lines | uncovered_lines | Number of lines of code which are not covered by unit tests. |
Uncovered lines on new code | new_uncovered_lines | Identical to Uncovered lines but restricted to new / updated source code. |
Unit tests | tests | Number of unit tests. |
Unit tests duration | test_execution_time | Time required to execute all the unit tests. |
Unit test errors | test_errors | Number of unit tests that have failed. |
Unit test failures | test_failures | Number of unit tests that have failed with an unexpected exception. |
Unit test success density (%) | test_success_density | Test success density = (Unit tests - (Unit test errors + Unit test failures)) / Unit 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.