Skip to main content

JavaOne Blog 7: Is code review old school?

Posted by malcolmdavis on May 10, 2007 at 11:23 AM PDT

There are numerous sessions on automatic bug detection that stretches to all types of development practices.

The concept of increasing quality to lower cost has been around for decades. There have been empirical studies, and Steve McConnell does a nice discussion at

When conducted incrementally and daily, code reviews are low cost quality measures.

I’ve conducted daily reviews for a staff of 12 developers. I dedicated 1-hour of every morning to the review task. This was extremely helpful to people new to the staff and or technology. Resolving issues in beginning with people new to the technology is extremely important. I found daily reviews to be a cost effective solution for traditional (non-agile) development environments.

Empirical data shows that code reviews have a high pay off than unit test.

In the Java arena, there are a number of free and open source software (FOSS) offerings that can do automated rules review. The rules can be anything from the basic to complex rules validation.

Normally, I just have everybody turn on all compiler warnings. The compiler warnings catch everything from unused variables to null pointers, bad naming conventions, and much more. [The IDE I use even goes as far as pointing out misspellings in the code comments and documentation.]

Tools like Findbugs (FOSS) take the compiler warnings to another level by allowing developers to write their own rules. Findbugs is easily
integrated into the build processes such as Ant and Maven.

Hence, the concept of code review to find ‘rules validation’ is old school.

I think code review should be utilized to find misuses of the technology, bad programing, etc. For instance, many developers new to Java do NOT realize that there is a String Tokenizer in the Java API, and code their own. The Tokenizer is something that shows up repeatedly. Other common problems include bad interface design, limited or no unit testing, cloned code, etc.

However, all the problems I just mentioned are vastly disappearing. There are FOSS tools that determine the quality of design, the level of unit testing coverage, and search for cloned code. Each of the tools can be integrated into the daily build process.

Hence, the job is moving more from ‘code review’ to constructing a proper build process.