Code review checklists are usually a pain. They're often ridiculous in length or content. They're not fun to use. Sure we want processes to find defects in our code, but there's got to be a better way than a "Checklist for C" the boss downloaded from some website. Checklists can be an excellent way of finding defects early in the development process, but most of the time checklists are so impractical that they're more of a hindrance than a help.

Twenty-eight--that's the average number of checklist items I found in the top seven sample checklists from the Internet (according to Google, the Knower Of All). My field experience is similar; it's not unusual to find two pages of items, each requiring due consideration before its own white square can be checked.

Mammoth checklists are built with the idea of completeness. The list is usually divided into categories: correctness, maintainability, style, error handling, performance, mind-numbing, and so on. Items range in scope from generic concepts like "Function does what it is documented to do" to specific checks like "strncpy() is used instead of strcpy()."

In reality, these checklists are useless. If someone stacks 20 files on your desk and insists that a 30-item checklist be applied to each file, how would you even go about that? On the 12th file are you really going to be diligent on every item?

Here's what actually happens. People use the list as a general guide. They don't consider every item in every file. Which items will they remember as they look at the code? Will it be the most important ones?

Magic numbers
In 1956, George Miller published a now-famous paper called "The Magic Number Seven, Plus or Minus Two." He measured human short-term memory capacity for "chunks of information." For example, most people can remember an American seven-digit local number long enough to dial it, whereas when dialing a ten-digit long-distance number, most people have to refer back to the number at least twice.

Miller's results have been applied to various aspects of psychology and even computer science. For example, Miller's work is frequently cited as a reason for limiting a function's cyclomatic complexity to nine.

If we expect reviewers to think about the entire checklist when reviewing a file, we have to keep the checklist short. Five items sounds good; maybe as many as ten. So that's the first rule: List no more than ten items.

Getting away with five
With only a few checklist items, how will we still catch the same number of errors with code correctness, maintainability, and style? In my experience, long checklists contain mostly simple programming rules or coding style checks. Style items include naming conventions, whitespace, block positions, and comments usage. For embedded C programs, style rules are things like "Use underscores to separate words, not CamlCase" and "All functions must have a comment block in a certain format."