tools.cdt Plugin PmdAnalysis

PMD Configuration analysis for tools.cdt

PMD is a great and widely-used source code analyzer which finds common programming flaws and bad coding practices in source code projects. This document intends to help users configure the tools and select the right rulesets for a more efficient use of the tool.

  • The quick summary helps users understand the reports generated by the tool
  • The rulesets overview provides basic information about the rulesets detected in the violations.
  • The rules selection section proposes to remove rules that produce too many violations to be actionable and have a low priority, to allow users to better focus on pragmatic actions.
  • Finally, the continuous improvement section proposes steps to incrementally improve the quality of your project.

The version of PMD used is 5.3.1 and the PMD run was executed on the 2018-11-17 00:31:46.

You can learn more about this module on its documentation page on the project web site.

Quick Summary

PMD raised a total of 181408 violations to checked rules, including:

  • 1152 with priority 1,
  • 2017 with priority 2,
  • 175733 with priority 3,
  • 2506 with priority 4.

Rules can be considered as coding practices. They represent what the community believes to be right or wrong, althougth it heavily depends on your own context. In this very case:

  • A total of 87 rules have been checked.
  • The analysis found 71 broken rules, and 16 respected rules.
  • So the rate of acquired practices is 18.4 %.

This plot shows the proportion of rules violated (NOK: red) and clean (OK: blue). The lightness decreases with the priority (P1 -> p4).

Improving PMD usage

Having too many violations just does not help. Most developers will feel overwhelmed by thousands of violations, and from a practical point of view they just wont spend days or weeks fixing violations on a product that works - would you yourself?

That is why it is important to customise PMD to fit your needs. It usually boils down to the following steps.

Investigate rulesets

If you are quite new to PMD, the first thing to do is to investigate and try the rulesets. Start with some of the obvious rulesets - just run unusedcode and fix any unused locals and fields. Then, run basic and fix all the empty if statements and such-like. Then peruse the design, coupling and controversial rulesets.

The bottom line is to find rules that are both important - you can rely on the priority of the rule for that - and actionable, that is they do not show thousands of violations. The latter is because beside the fact it is discouraging for developers, it means that your project is probably not mature enough regarding this practice. Start small, secure practices, and expand the scope.

The rulesets detected in the current PMD log are Basic, Coupling, Design, Unused Code, which represent a total of 87 practices checked. The following graphic shows the number of violations classified by ruleset. Violations are sorted according to their priority, from 1 (high impact) to 4 (information). The table on the right provides the data for this graph, with the overall number of violations for each ruleset, and for each priority.

Rulesets detected in this PMD analysis.
Ruleset NCC NCC_1 NCC_2 NCC_3 NCC_4
Basic 1320 2 66 1252 0
Coupling 142535 0 0 142535 0
Design 27217 1150 1951 24116 2506
Unused Code 7830 0 0 7830 0

Select and customise rules

Once you get to know what rules are available, and started identify some of them as really smart and relevant for you, you should then create your own ruleset. Creating your own ruleset makes it easier to run PMD by selecting entire rulesets, excluding or specifically adding specific rules. It also gives you more control over the analysis' execution by excluding some files or directories.

The following graphic shows all rules violated in this project's code, sorted according to the number of violations. The colour of the bars varies from red (priority 1) to yellow (priority 4). Please note that the y axis is logarithmic, so small numbers can still be identified despite the high-volume rules.

At least during the early steps, rules with a high number of violations (e.g. > 500) and a low priority (like P3 and P4) can simply be discarded. On the above plot, they correspond to all yellow bars to the right of the last right red or orange bar. In the current case there are 18 rules that can be excluded, which represent together 174661 violations. They are listed in the table on the right. By removing these rules, the number of violations should fall down from 181408 to 7254.

If some rules seem to be relevant but give unexpected results, try to tune them. Many rules can be given properties to alter their behaviour. As an example, the EmptyCatchBlock rule from the basic ruleset has a Java property allowCommentedBlocks to skip empty blocks comments for this rule.

Rules that can be removed to lower the number of violations.
Mnemo priority vol
LawOfDemeter 3 141031
UnusedModifier 3 6826
FieldDeclarationsShouldBeAtStartOfClass 3 5991
ConfusingTernary 3 3470
ImmutableField 3 2959
UseVarargs 4 2506
AvoidReassigningParameters 2 1951
UncommentedEmptyMethodBody 3 1571
CollapsibleIfStatements 3 1144
GodClass 3 1116
AvoidDeeplyNestedIfStmts 3 1083
CompareObjectsWithEquals 3 1047
SwitchStmtsShouldHaveDefault 3 801
ExcessiveImports 3 753
LooseCoupling 3 698
UnusedLocalVariable 3 634
AvoidSynchronizedAtMethodLevel 3 573
AvoidConstantsInterface 3 507

Continuous improvement

Well, if you did that already you should have a much more concise and clean perspective on PMD results. Improving the project quality is probably the best thing to do now, at least to catch the most important bugs (with the highest priority). Once you are done, come back to this section and try to add some more meaningful rules to continuously improve your code.


The visualisations on this page can be exported and easily reused on an external web site. You can find more information on iframes and pictures reuse in the project's web site. Remember to change the server name in the code samples provided.

Pie chart of checked and broken rules

<iframe src="http://server/projects/tools.cdt/PmdAnalysis/pmd_configuration_summary_pie.html" frameborder="0" style="width: 100%; height: 320px"></iframe>

Files with high priority violations

<img src="http://server/projects/tools.cdt/PmdAnalysis/pmd_configuration_rulesets_repartition.svg" frameborder="0" style="width: 100%; height: 600px" />

Top 5 high-priority rules

<img src="http://server/projects/tools.cdt/PmdAnalysis/pmd_configuration_violations_rules.svg" frameborder="0" style="width: 100%; height: 600px" />

The visualisations used in this document rely on a number of flat CSV and JSON data files, that were extracted from the PMD XML results file. You can download and play with them if you want to thereafter:

  • Generic information about the project : PMD version, timestamp of analysis, number of non-conformities, number of rules checked, number of rules violated, number of clean rules, rate of acquired practices [ Download CSV ]
  • Rules: number of non-conformities for each category of rules and priority [ Download CSV ].
  • Violations: foreach violated rule, its priority, the ruleset it belongs to, and the volume of violations [ Download CSV ]
  • Files: for each non-conform file, its name, total number of non-conformities, number of non-conformities for each priority, number of broken and clean rules, and the rate of acquired practices [ Download CSV ]
  • Rulesets detected in the analysis output, with number of violations for each priority [ Download CSV (wide format) | Download CSV (long format) ]
  • List of violated rules, with priority, ruleset and number of non-conformities [ Download CSV | Download JSON ]

Page generated by Alambic 3.3.3-dev on Fri Jan 15 16:49:51 2021.