Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/pmd/pmd/issues/445 below:

the three *CyclomaticComplexityRules should be merged together · Issue #445 · pmd/pmd · GitHub

Rule Set: java/codesize

Description: The codesize ruleset currently has three different rules to calculate variants of the Cyclomatic Complexity (Cyclo) of a class/ method:

• StdCyclomaticComplexityRule: The de facto standard Cyclo metric in PMD. Every control flow statement counts as +1. Switch cases count as one, but not the switch itself ---the point is that a switch should have the same Cyclo value as the equivalent series of if statements.
• CyclomaticComplexityRule: Adds the number of paths boolean expressions can take (equivalent to the number of && and || operators in the expression) to the value of the previous metric
• ModifiedCyclomaticComplexityRule: First version but also counts switch statements as 1

I've refactored those rules to use the new Metrics Framework (coming soon!), however I don't see the point of keeping them separated, for the following reasons:

• Cyclomatic complexity has a standard, which seems to be the version of the second rule:

  • McCabe's original 1976 paper states that we should count paths in boolean expressions (see page 315 second paragraph on the left). The second document also precises that this is only true in languages with "short-circuit" boolean expression semantics (lazy evaluation).
  • This second document shows on page 24 and 26 (34 - 36 in the pdf) that the complexity of a switch is the number of labeled case statements (that is, without counting the switch itself nor the default case) for languages which have a default switch case (like Java and C).

• We currently label the first version as standard, and give the three variants the same importance by giving each one its own rule

• The names of the three rules couldn't be less descriptive, which probably adds to the confusion

I've been working on the ability for metrics to accept options to easily amend part of their behaviour. I believe Cyclo should only be one metric, of which variants can be selected via an option.

I think we could make one rule to rule them all from the three existing ones, and enforce the "standard" calculation of the metric as default behaviour (nice but not essential). The variant could be selected via a rule property. Merging the three rules would only be suitable for a major version but hopefully we can at least refactor them to use metrics once the ruleset schema is updated :) Comments?

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4