PMD meets Git (Part I)

PMD is one of the most widely-known open source tools to control coding style issues, which is specially popular among Java developers. It contains a complete ruleset with the most common bad practices.

The easiest way to start using it, is installing it with Homebrew (MacOS) or Linuxbrew(Linux), but for other platforms, you can also download it from their official website.

brew install pmd

To run PMD over a project, we need three mandatory parameters:

pmd pmd -d MYPROJECT -rulesets java-basic,java-design

• The application name (pmd, cpd, cpdgui, designer, bgastviewer): PMD to analyze code patterns, CPD to analyze code duplications and the others to design new rules.
• The files/directories to analyze (-d).
• The rulesets to apply (-rulesets).

After running PMD, this tool will produce a report in the standard output with all the issues of our files.

/Users/rpau/tests/test/src/main/java/org/walkmod/Bar.java:5: Document empty method body
/Users/rpau/tests/test/src/main/java/org/walkmod/Bar.java:22: Useless parentheses.
/Users/rpau/tests/test/src/main/java/org/walkmod/Bar.java:32: A switch statement does not contain a break
...

However, we usually have the following reaction:

Ok.. there are a lot, and we do not have time now to fix everything. Which are the most important issues to fix?

Usually, the answer consists of those issues that appear in the most important files. Thus, the problem is deciding which are these files, which are known as Hotspots.

In our opinion, the most critical files to maintain are those files that:

• Are recently modified with pending issues to fix. Project priorities are over these files and improving their coding issues will have an immediate benefit on the next days/sprints.
• Are constantly modified and contain some pending issues. According to the Open-Close Principle, good designs are open to extensions and close for modifications. Design issues have more impact than readability issues because make us to follow a programming pattern across many functionalities. Determining those files with a high modification frequency with pending issues could help us to fix design issues first.
• Have been modified during the last months only for the same person and contain pending issues to fix. What happens if this developer is hit by a bus? (i.e Bus Factor). Analyzing the contents of those files could be a nightmare for the rest of the team and would reduce our productivity, which also means technical debt.

Working with temporal Hotspots, gives us a plan to incrementally improve our code base.

In order to do so, we need to integrate our PMD results with Git, which contains all the history of changes of our project. This idea of using Git as a dataset to discover design problems was initially driven by Adam Tornhill.

Using the git blame command, we can resolve the last timestamp and author of each line of code. However, running PMD for each commit, specially for those projects with a lot of legacy code, is computationally expensive. Git blame can be used as an heuristic to define when and who was the author of a PMD issue, which may help to identify hotspots.

You can experiment the result of that approach with our tool called WalkModHub. You can simply install and run it with Docker Compose. Here the commands:

wget -O docker-compose.yml http://tinyurl.com/jogxhgb
docker-compose up

After our service is up (in your docker-machine or localhost at port 80).

http://localhost:80

Now, register your user, your repository (public or private) and voilà, you will get the results.

If the repository has a ruleset.xml file, WalkModHub will apply your rules. Otherwise, it will apply all PMD rules for your programming languages.

What do you think? Are the calculated hotspots valid for you? Do you appear in the ranking of the best developers of this month? ;)

Git can also help to determine which are the new issues you have created before committing those changes. We will explain it into our next post.