Code Review Checklist - why every one wants to write one?

In my previous blog, I have report some of the recommendations from Robert Glass on Software standards and how they should be developed.

Today, I was asked to review a Code Review check list for .Net development submitted by a development group. Granted that Code Review Checklist is not the same as standards but more like a form of guidelines it should be written at least by someone that knows the stuff.

After spending some time reviewing the contents, which is made up of something like 30 items, I was horrified at such a low quality. Clearly the author of this check list has only had superficial knowledge of .Net. One example to show the naive level of knowledge is the demand that all string comparison should be performed in lower case. Clearly this person has not read this article. Another is the incorrect exception handling technique to look for in this checklist.

Some of the mistakes made, like method and parameters naming conventions, give an idea that the author's background is really in Java.

It begs the question why someone wanting to write a check list when FxCop has already contained one far far more extensive that this novice has been able to muster. There is even a book on the guidelines. So why bother?

In fact, the first item of the check list should demand a clean run of FxCop or VSTS Code Analyzer. Other check list items should be more about advanced issues like couple metrics, design patterns and complex issues, any unit tests and are they constructed in the spirit of Unit Test, etc.

The check list, as Robert Glass said,

should be written and reviewed by the best programming talent in the shop, not by whomever happens to be available at the moment.

This is not the first time nor will this be the last for me seeing this kind of mistake.

Software Standards and how to develop and use it properly

Over time, I have come across many attempts by software engineers from different development shops or organisations and have formed an opinion that many of these attempts are not only poorly compiled but often containing dangerous information. They are better served by adopting world recognised publications but there are very few that are well written and of International standard quality.

I have never been able to find any publication to back up my observation and opinion until I come across the chapter titled "Standards and enforcers: Do they really help achieve software quality?" in a book called "Softeware Conflict 2.0 - The Art and Science of Software Engineering" by Robert L. Glass.

This chapter not only supports my opinion but also clear my doubt of whether or not adherence to software standard produces quality software by his explanation that:

Standards are a narrow subset of the total issue of quality, and although it would be nice to establish the definitions of quality in terms of conformance with a sufficient set of standards, it is simply not possible. Software quality is defined in terms of attributes such as portability, efficiency, human engineering, understandability, testability, modifiability, and reliability.... you will quickly see the software quality cannot simply be legislated, it must be performed. Efforts to measure software quality in terms of standards conformance are doomed to letting poor-quality software slip through undetected.

While conformance to standards alone does not necessary produce quality software, he has found:

They do indeed help software quality and software productivity. But they must be done right. There are many pitfalls along the way, and many people aren't doing them right.

So how do you do it right? Here are his recommendations:

First of all, standards should be terse and to the point. The must rules for writing software, no matter what the installation, should be distilled into a short manual which can be digested quickly, applied easily, and enforced conveniently..... Guidelines, not standards, should be established. This document may be as long as it needs to be, because it contains helpful hints which most programmers will want to read, and length will not be a problem since there is no need or even intention of enforcing these rules.

Second, standards should be written and reviewed by the best programming talent in the shop, not by whomever happens to be available at the moment.
[...]
Third, enforcement of standards should be mandatory, not something done if there happens to be time.... Enforcement processes should include automated enforcers where possible (these are sometimes called code auditors), and the use of reviews as necessary where automation is not possible. Peer code reviews are one important way of doing standards enforcement, although the main focus of such a review should be on quality as a whole, not just standards enforcement.

Finally, Glass has this warning to Quality Assurance group:

Often quality assurance organizations will perform standards enforcement activities, and pronounce the software to be of high quality.