A small step to source code quality improvment

Today I would like to share some basic source control checkin rules with you that work well in agile teams and support the QA process. Actually i've seen some projects that would be happy if that was their QA process ... ;-)

These steps don't cause much formalism or other overhead (or cost a lot of time if applied regularly) and greatly help to keep your team-colleagues as friends ... :-)

Basic Checkin Rules: Before Classes are checked in, they ...

• must compile!
• must contain useful JavaDoc like a Class description and meaningful doc for all public methods, i.e. this often means "add missing documentation" (not neccessarily for getter/setter and also optional if JavaDoc can be "inherited" from base class)
• must be Checkstyle compliant and be formated (using project standard configurations that are mandatory for all developers) (Eclipse Plugin: http://eclipse-cs.sourceforge.net/)
  
• must be scanned and cleaned with Findbugs for BadSmells, etc ... (Eclipse Plugin: http://findbugs.cs.umd.edu/eclipse/) // If a found item is not fixed on purpose you need to have a good reason/explanation
• must be free from System.out.println and therefore must use (don't overdo this) "if (LOG.isDebugEnabled() ) LOG.debug(...)"
• must contain a useful and traceable SVN/CVS commit message
  

The senior developers/architects/scrum master/project managers or similar should do random-samples from time to time and the team mates should "force" each other to stick to these rules for the sake of the whole team (times of code ownership are over). If possible, a continuous integration tool should automatically check some of these source code quality attributes regularly.

Note: These rules don't help necessarily the quality of the algorithms or business logic that you write!

The source code is some kind of business card that is left at the customer site when the project is over and so it must be taken care of ...

Although this is not a silver bullet for a total turn-around if your code quality is crap, it could be a start for improvement or a great starting point if you start on the "green field" and don't have all processes and guidelines in place yet.

I hope that some ideas are useful for you ... try it out ... and as usual: Don't hurt yourself!

~Wolfgang