Skip to end of metadata
Go to start of metadata


  • Set up rules and generate the relevant reports.
  • Modify rules and fix bugs until the whole development team agrees on the standard.
  • Be absolutely certain that the standards are understood, agreed upon and followed before continuing.
  • Add checks to the regular build to enforce that the standards are followed. In most cases it is a good idea to make the regular checks less strict than the actual standards. This does not imply that you should have two sets of rules or that developers don't have to follow all the rules. It only means that you should not break the build if some code is entirely up to the QA standards. The reasoning is that it must be possible to do quick prototyping, proof-of-concepts, etc. without the CI server firing off a bunch of angry build error emails.

Available plugins

Findbugs, PMD, CPD
Cobertura, Emma, Clover

See Java Parent POM Example for a complete pom.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Apr 02, 2009

    Hopefully people realize that automated code review cannot substitute all benefits of human code review, such as design flaws, good naming, documentation, good enough test cases, sharing knowledge, etc.