[java] RFC: Is StatisticalRule still relevant?

[oowekyala]

Rule Set: java-codesize, java-design

I'm wondering if StatisticalRule's architecture is still relevant given that the Metrics framework allows a simpler way to write rules that use metrics (see eg. this refactored version of CyclomaticComplexityRule).

• I have a feeling StatisticalRules are harder to write and maintain than regular rules. The architecture of StatisticalRule and its helpers is built around the premise that the rule that will implement that interface will use its visitor to collect "data points", that is, to calculate the metric being tested, and not to report violations (instead that's done in the helper). The upcoming Metrics framework enable the metrics computation to be done completely outside the rule itself, thus the rule's visitor can be used to file violations (as it's supposed to be doing), and there's no longer need for this complicated architecture.
• Moreover, I think rules that use metrics such as StatisticalRules may be easier to maintain if their implementation was not spread across four or five files. For instance NcssTypeCountRule extends AbstractNcssCountRule, which extends AbstractStatisticalJavaRule, which implements StatisticalRule, and uses StatisticalRuleHelper. That makes the implementation of this rule dispersed over five files, which means it's very much harder to maintain and refactor. Using the metrics' framework or a similar approach, that rule could simply extend AbstractJavaRule, like any other.
• Some StatisticalRules use some kind of node counting as their "metric" (eg subclasses of ExcessiveNodeCountRule). While imo these measures should not be written as fully fledged metrics, and integrated into the framework, I think we could use another approach to calculate them regardless. If we define a custom visitor object to calculate the metric, then the computation logic is nicely isolated from the violation reporting logic. A small example:

public abstract class ExcessiveNodeCountRule extends AbstractJavaRule {

  private Class<?> nodeClass;
  int level = 10;

  protected ExcessiveNodeCountList(Class<?> nodeClass) { this.nodeClass = nodeClass; }

  protected abstract JavaParserVisitor getVisitor();

  public Object visit(JavaNode node, Object data) {
    if (nodeClass.isInstance(node)) {
      int count = ((MutableInt) node.jjtAccept(getVisitor, new MutableInt(0))).getValue();
      if (count > level) {
        addViolation(data, node);
      }
    }
  }
}

public class ExcessiveParameterListRule extends ExcessiveNodeCountRule {

  public ExcessiveParameterListRule() {
    super(ASTFormalParameters.class);
  }

  @Override
  protected JavaParserVisitor getVisitor() {
    return new JavaParserVisitorAdapter() {

      public Object visit(ASTFormalParameter node, Object data) { 
        ((MutableInt) data).increment(); 
        return data; 
      }
    }
  }
}

That looks very much like what's done in the metrics framework to calculate Ncss for example. Writing node counting rules in a similar way could help us avoid StatisticalRule's complexity.

Do you see reasons why StatisticalRule is still handy ?

[adangel]

I agree, that the StatisticalRules don't look necessary anymore with the metrics framework. While the statistical rules allow to report based on a minimum / sigma / top-score threshold, it seems, only the minimum threshold is used. All rule properties have no default value, and I doubt that anyone used the other properties. If really needed, we have something like this with the "ResultOption" calculation.
In general, the Statistical rules operate only on one class, while the metrics framework is capable of analyzing/comparing different sources (within one PMD execution).
In the long run, I think, we should try to re-implement these rules with the metrics framework (if possible) or simplify them (as you suggested).

[adangel]

This issue is not relevant anymore. StatisticalRule is deprecated since PMD 6.11.0 (#1550) and will be gone with PMD 7.0.0 (#1750, #1772, #2005)