In this the last part of this four-part series I will zoom carefully into the ease of use of PMD. I totally enjoy PMD. The reason for this is the relative simplicity of writing your own bug pattern-capturing rules and using them under fire. More on that later. To round off we have included an in-depth interview with Tom Copeland, the author of PMD Applied and the newer JavaCC . It is no coincidence that Tom is at the center of the PMD development thrust.

Note: this is Part 4. Feel free to read Part 3!

In the previous posts, I have written about personal use of static code reviews via a GUI, in this case Eclipse. However, for large projects with hundreds of thousands of lines of code or more, with the code base being scattered amongst project teams, we have a problem. The economics of Quality Assurance demand a more mass analyzed and factory-efficient approach. Do things quick, hit the code, find the worst bugs and repair. The white box looking out, in combination with the functional or load testing black box methodologies looking in.

Note: this is Part 3. Feel free to read Part 2!

Static code reviews aimed at eating bugs (!) are unbiased and neutral. If you spill coffee on their laps or are applying for the same job as them, the advice given back will remain the same. Static code reviews work via rules; some rules are accurate in their assessment and others are not so relevant—or even false. Before building a thorough infrastructure for large-scale deployment, it is well worth installing the tool’s respective plugins. You can have a lot of fun kicking the tires of the rule sets for your own particular environment. Getting your fingers into the reality of the code is the first step in the path to Quality Assurance enlightenment. Note to self, remember to ask boss for pay rise.

Note: this is Part 2. Feel free to read Part 1!