The Disco Blog

Peer based code reviews are generally considered copasetic to the overall quality of a code base because they present opportunities for an objective analysis via a second pair of eyes. For this same reason, XP’s pair programming ritual offers some of the same objective analysis benefits. Even static source code analysis tools like Java’s PMD or .NET’s FxCop, which scan files for violations of predefined rules, offer some of the same analysis benefits.

All three of these techniques for code analysis (code reviews, pair programming, and static code analysis), however, are marginally useful if they are capriciously applied- the simple reason being that their analysis benefits fade over time without proactive reinforcement. Moreover, the first two techniques, code reviews and pair programming, are performed by humans, who are error prone and have a limited capacity when compared to computers (and disco moves).

Code reviews, when conducted efficiently, can be impressively effective; however, they are run by mortals, who tend to be emotional (meaning that it can be difficult for a colleague to tell another their code stinks). More importantly, people collaborating in a work environment have the tendency to subjectively review one another’s work. There is also a time cost associated with code reviews, even in the most informal of environments.

Pair programming has also been shown to be effective when applied correctly. Having another pair of eyes constantly reviewing code can yield higher quality code; however, organizations practicing this innovative technique are in a minority. Pairs also suffer the same issues of emotion and subjectivity (disco dancing is another story, however).

The difference with a static analysis tool is two fold, however. First, these tools are incredibly cheep to run often. They only require human intervention to configure and run once- after that they are automated. Thus, these tools offer a time saving aspect. Second, these tools harness the unflinching and un-forgetful objectiveness of a computer. A computer won’t offer those “your code looks fine if you say mine looks fine” code review compromises nor will your computer complain about bio-breaks and personal time if you decide to run an inspection tool every time the CM repository changes.

These tools are also customizable- organizations can choose the most relevant rules for their code base and run these rules every time code is checked into the source repository. These tools become, in essence, tireless watchers of source code, which is practically impossible to mimic with human intervention.

These tools also work incredibly well in geographically distributed environments (i.e. some developers working from home, others at the office, and others in another state, country, continent, etc). Having a human manage the review of all code in this scenario is a costly proposition!

Automated static code analysis scales more efficiently than humans for large code bases; furthermore, some tools offer hundreds of different hip rules, which a human can’t possibly remember while reviewing a series of files. Moreover, running a tool’s myriad rules against your code base will take less time than having your partner review one package.

Automating code inspections with analysis tools handles 80% of big picture and allows humans to intervene in the 20% that matters. For instance, Java’s PMD will run 180+ rules against a file every time it changes. If a particularly concerning rule is violated, such as a high cyclomatic complexity value, someone can take a look. Can you imagine trying to accomplish this process manually? Why would someone want to? That’s so establishment!