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:
1152with priority 1,2017with priority 2,175733with priority 3,2506with 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
87rules have been checked. - The analysis found
71broken rules, and16respected 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.
| 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.
| 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.
Downloads
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.