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 version of PMD used is
5.3.1 and the PMD run was executed on the
PMD raised a total of
37156 violations to checked rules, including:
50with priority 1,
13with priority 2,
37045with priority 3,
48with 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:
87rules have been checked.
53broken rules, and
This plot shows the proportion of rules violated (NOK: red) and clean (OK: blue). The lightness decreases with the priority (P1 -> p4).
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.
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.
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
1 rules that can be excluded, which represent together
35165 violations. They are listed in the table on the right. By removing these rules, the number of violations should fall down from
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.
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/modeling.emfcompare/PmdAnalysis/pmd_configuration_summary_pie.html" frameborder="0" style="width: 100%; height: 320px"></iframe>
Files with high priority violations
<img src="http://server/projects/modeling.emfcompare/PmdAnalysis/pmd_configuration_rulesets_repartition.svg" frameborder="0" style="width: 100%; height: 600px" />
Top 5 high-priority rules
<img src="http://server/projects/modeling.emfcompare/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:
Page generated by Alambic 3.3.2 on Sat Nov 18 05:05:48 2017.