Understanding Code Complexity Metrics and Using PMD and JavaNCSS to Manage Long Methods and Classes

I openly admit that encountering complex code blocks can be intimidating, as large numbers of methods and sprawling classes increase testing difficulty, maintenance effort, and error rates.

Previously I discussed cyclomatic complexity as a warning sign of problematic code; using the Extract Method refactoring pattern can reduce complexity and improve testability, as illustrated in Figure 1.

However, cyclomatic complexity is not the only metric—class length, method length, and internal class coupling also matter, and I will show why they are important and how to track them with PMD and JavaNCSS.

Understanding the difference between simple and convoluted code is crucial; simple code need only be easy to understand, regardless of the language used.

Human cognitive limits (roughly 7 ± 2 items) mean that excessive conditions or logical blocks quickly become hard to manage.

Long methods contain many grouped statements with a common goal, but the sheer number of logical blocks can obscure the method’s overall intent, leading to maintenance problems; similarly, long classes suffer from excessive responsibility.

What counts as “too long” is subjective: a common rule of thumb is that any non‑comment line count over 100 indicates a long method, though many developers use a cutoff around 50 lines; for classes, thresholds of 500–1,000 lines are often cited.

Internal class coupling further complicates matters: importing more than 80 external classes (excluding standard Java libraries) suggests high outgoing coupling, while wildcard imports can mask true dependencies; counting unique types can provide a clearer picture.

Classes with many public methods also tend to have many imports, creating high incoming coupling and increasing fragility when any of those classes change.

These metrics are interrelated: long methods usually exhibit high cyclomatic complexity (Figure 2), and classes with many imports often have many unique types, become large, contain long methods, and thus have high complexity (Figure 3).

PMD is a rule‑based engine that analyzes source code against roughly 200 predefined rules, including those for method length, class length, unique types, and public method counts; rules can be customized or extended.

For example, the <rule ref="rulesets/codesize.xml/ExcessiveMethodLength"> <properties> <property name="minimum" value="50"/> </properties> </rule> rule lowers the default threshold of 100 lines for a method to 50 lines.

When invoking PMD via Ant, a custom ruleset file can be referenced as shown: <pmd rulesetfiles="./tools/pmd/rules-pmd.xml"> <formatter type="xml" toFile="${defaulttargetdir}/pmd_report.xml"/> <formatter type="html" toFile="${defaulttargetdir}/pmd_report.html"/> <fileset dir="./src/java"> <include name="**/*.java"/> </fileset> </pmd>

PMD reports only violations; in the example (Figure 4) only a few methods exceed the 50‑line threshold.

For large classes, PMD provides the ExcessiveClassLength rule (default 1,000 lines) and rules such as CouplingBetweenObjects and ExcessiveImports to assess coupling.

JavaNCSS complements PMD by reporting code‑length metrics for every file—class size, method size, and method count—without a fixed threshold, offering a fuller view of the code base (Figure 5).

In conclusion, whether starting a greenfield project or tackling legacy COBOL‑based systems, applying complexity metrics to class length, method length, and internal coupling is the first step toward understanding and managing code difficulty; begin with heuristic thresholds and then employ tools like PMD and JavaNCSS for deeper analysis.