Generate cumulative statement / complexity metric for need of methodContext filtering

A method context has maxComplexity / maxStatements attributes which allow to reduce the scope of context filter for methods where these metrics are lower than defined level (by default maxComplexity/maxStatements is Int.MAX_VALUE, i.e. all methods are taken into account). Example:

<methodContext name="trivial" regexp=".*" maxStatements="1"/>

However, customer reported a problem that it excludes methods containing inline classes, for instance:

// the getListener() method has only one statement: "return <object>;"
// if you use <methodContext name="trivial" regexp=".*" maxStatements="1">
// then the whole code block will be filtered-out, including the actionPerformed() method
ActionListener getListener() {
   return new ActionListener() {
       public void actionPerformed(ActionEvent e) {
           System.out.println("statement #1");
           System.out.println("statement #2");
       }
   }; 
}

In the case above ActionListener() is an inner class so it has their own metrics. And because of fact that context filters are "cumulative" (so that whenever any code pattern is matched, then the whole block is excluded), the whole getListener() method is filtered-out, including inner class.

Solution:

We cannot change existing metrics (without breaking backward compatibility) and we cannot change the way how blocks are excluded (it would make no sense). But we can create new metrics called: cumulativeComplexity and cumulativeStatements. It would work as follows:

• for every interface, class, enum or method find all inner classes, interfaces, enums or methods
  • this can be checked by matching occupied code regions (on a database level during metric calculation - preferred) or during instrumentation (code parser)
• calculate cumulativeComplexity and cumulativeStatements by adding cumulative value from all inner objects to current entity complexity/statements value
• add maxCumulativeComplexity / maxCumulativeStatments to Ant clover-setup/clover-instr and Maven clover2:setup / clover2:instr goals
  • html reports would probably remain unchanged (just grey-out)

yes we should make code more flexible in order to make it ready to support code constructs like default methods in Java8 interfaces or Scala's functions inside functions etc