What Code Review Should Not Find
I write so much about code review that I may forget to emphasize the obvious.
First, “code review” means different things to different people. I mean only that
Someone, who knows good code when s/he sees it, reads the code and gives the code author helpful comments.
Second, code review is not a goal — only a means to an end. The goal is better code now, and better developers as time goes on (which means better code in the future).
That said, I can get to today’s point, which is:
Code review is expensive, so use it wisely.
Do Not Use Code Review
Do not use code review to ensure that fixed text, such as copyright notices and authorship headers, are correct. For those, create code file templates and use them.
Do not use code review to find text layout problems. Instead, adjust your code editor so that it helps you lay the text out according to your style guide, and only lets you lay it out that way. In fact, skip the style guide — write a code editor configuration file, and perhaps some macros, instead.
Do not use code review to find where the language has been used incorrectly or unclearly. The person who wrote your compiler did that work already. Just turn the compiler warnings all the way up, and maintain zero compiler warnings. (And as Gerard Holzmann says in his rule #10, “The rule of zero warnings applies even when the compiler or the static analyzer gives an erroneous warning: If the compiler or analyzer gets confused, the code causing the confusion should be rewritten.”
Do not use code review to look for functional errors. Write unit tests instead. Not only is the CPU faster than a reviewer, and never gets bored, but the activity of writing unit tests often helps the code author see functional errors him/herself.
Do not use code review to find misuse of the language where the construct is error-prone. Consider the costs and benefits of moving to a language more suited to your environment, product, and developers, and if benefits outweigh costs, migrate to the better language.
Finally, do not use code review to find more instances of a problem if root cause analysis of past failures has already identified the problem as serious and systemic. Correct the problem first.
What’s Left for Code Review?
After all of the above is being addressed, then the valuable time of your code reviewers can be invested identifying readability, maintainability, and extensibility issues. For the most part, it takes a person to identify these issues. The reviewer is standing in for another developer—the one who will have to work on the code next.
These issues are the ones which affect how long it takes to fix, change, or extend the code, and how often fixes are required. The time saved by code that addresses these issues is what your time investment in code review is supposed to return, hopefully several times over.