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.

More details

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.

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

More details

Density of comment lines = Comment lines / (Lines of code + 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

Duplicated blocks

duplicated_blocks

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 as well as in string literals are ignored while detecting duplications.

Density of duplication = Duplicated lines / Lines * 100

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.

Weighted issues

weighted_violations

Sum of the issues 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 > General Settings > General > General and set the Rules weight property. The default value is:
( (Blocker_violatons * 10) + (Critical_violations * 5) + (Major_violations * 3) + Minor_violations )

Rules compliance

violations_density

Rules compliance index (RCI) = 100 - (Weighted issues / Lines of code * 100)
If the value is negative, it is rounded to 0%. 

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

More details

Number of lines generated by Cobol code generators like CA-Telon.

Number of physical lines that contain at least one character which is neither a whitespace or a tabulation or part of a comment.

More details

Number of functions. Depending on the language, a function is either a function or a method or a paragraph.

More details

Number of public Classes + number of public Functions + number of public Properties

More details

Number of statements.

More details

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

Identical to Condition coverage but restricted to new / updated source code.

To be computed this metric requires the SCM Activity plugin.

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)

Identical to Coverage but restricted to new / updated source code.

To be computed this metric requires the SCM Activity plugin .

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)