News: Paul Duvall on continuous inspection with software inspectors

  1. Code reviews in projects tend to be the first thing sacrificed for the sake of delivery schedules. In his first article in a series on "Automation for the people," Paul Duvall discusses how "software inspectors," or static analysis tools like CheckStyle, JavaNCSS and CPD, can enhance the development process and explains when they should be used.
    With software inspectors, code inspections become automated through build tools like Ant or Maven. And it's through this automation that low-level source code details like coding standards, complexity, and duplication (to name a few) become the responsibility of a machine. This responsibility shift has the tendency to enhance in-person manual inspections by focusing on more high-level aspects of development, such as design and long-term maintenance issues.
    Duvall recognizes that there are many different inspectors out there, beyond the three he profiles. Once a continuous inspection process is in place, inspectors like JDepend, PMD or FindBugs can be plugged in. However, Duvall prefers CheckStyle, which can be run inside an IDE such as Eclipse, and how it "straightforwardly integrates into build scripts through its Ant task or Maven plug-in." Another benefit of CheckStyle is that Ant and Maven can be configured in concert with the tool so that builds can fail if any rules are violated. CPD, part of the open source static analysis tool PMD, is also among Duvall's top three.
    CPD...reports the number of duplicate lines in a code base. What's more, CPD's token threshold is configurable, meaning that you can vary how CPD suggests duplicate lines of code.
    Duvall also sings the praises of JavaNCSS - a free tool that provides "code measurements such as the number of non-commenting source statements and the cyclomatic complexity number of all analyzed methods." Duvall warns that continuous inspection shouldn't eliminate manual inspections - but automated inspection utilities can in fact increase the productivity and efficiency of the manual inspections that are performed. In addition, continuous inspection reduces risks at every step, rather than at the end of a project - especially when used with a CI tool like CruiseControl, which runs a predefined build script whenever a change is made to a version control repository so that teams can know to run a software inspector whenever a change is made. How beneficial do you find continuous inspection to be to the development process? Are you taking advantage of automated inspection? Which software inspectors have you used, and what are your experiences with them?
  2. FindBugs works well[ Go to top ]

    After code reviewing a bunch of code from an offshore team I found myself reporting numerous silly issues with the code that they returned. After asking them to run the FindBugs tool and fix their own code before they sent it, the code I was getting was much better and I could focus on more important issues.
  3. The project I run has 8 developers using Eclipse to develop traffic management applications. As we have to conform to IEC61508 safety procedures, code reviews for us are not optional but an absolute necessity. After investigating some tools to facilitate the review process, we have installed both the CheckClipse and FindBugs Eclipse plugins (and spent some time tweaking their parameters) and have also added their respective ant tasks to our main build scripts. This combination is really working a treat, with the time spent for module source code review slashed from 4-8 hours down to 1-2 hours The FindBugs plugin is still a bit "raw" but very usable. Kudos to both the Checkstyle and FindBugs teams for these great tools!