Metric definitions

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

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

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 && 

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

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
• &&
• ||
• ?
• ->

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)

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)

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)

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

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.

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%

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.

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).