In Automation for the people: Continuous Inspection, author Paul Duval discusses software inspection as a general technique for achieving quality, and suggests that it is a good idea to automate the low-level aspects of the inspection task, so that the manual inspection can focus on higher level issues:

Code inspections can take different forms. Some organizations use formal peer reviews, in which a developer's peers critique the code and offer ideas for improvements; other organizations exercise pairing, where one person types and the other is considering high-level design decisions and suggesting code improvements. Furthermore, some teams have another developer review their code in the form of a "desk check" before committing it to the version control repository.

Regardless of how an organization chooses to perform a code inspection, one thing is for sure: they're implicitly manual processes. And as I've found over the years, manual processes are error prone and tend to be forgotten when the going gets rough. Software inspections, however, don't always have to be manual; in fact, an entire genre of open source and commercial tools, which I dub software inspectors, are available to facilitate statically analyzing code (also known as static analysis tools).

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.

Duval provides working examples of using three such tools:

• CheckStyle - for checking code style against an agreeed-upon style standard
• JavaNCSS - for spotting code complexity
• CPD - for detecting code duplication

The author suggests that such automated inspection tools can be run at each code change using a continuous integration tool, such as CruiseControl, so that "your team can actively improve code in real-time instead of in latter cycles." Given that running such inspection tools at each code change will generate a huge amount of data over time, he suggests installing a threshold detector that only notifies developers if, for example, a certain number of coding standards have been violated or a certain level of complexity has been detected in a certain number of classes.

To what extent have you attempted to automate code inspection? What problems does it really solve, and what problems does it create?