Code Review is the process of reading and analyzing code and providing alternate implementations that improve style, speed, maintainability, and other important aspects of code. It can be done as early as during the coding process itself (i.e. pair coding) or as late as the analysis phase of refactoring legacy code. It can be applied to single subroutines or entire systems. It can provide powerful and cost effective results but it is so often ignored in many shops.

There are many levels of granularity where code review can be applied. A single small subroutine or a few lines of code can be quickly reviewed. The scope of the review is usually just on how the code can be improved or sped up. Larger amounts of code can be reviewed for style, commenting, API and other aspects as well. Complete modules and larger amounts of code can also be reviewed for architecture and design.

Code Review can prevent bugs before they happen, detect potential bottlenecks before they clog your system. It can shorten the learning curve for newcomers to your code base and be used as a training method. Doing Code Review with your staff has three major wins: your codebase is improved, your staff's coding skills get better and your staff's understanding of your codebase is increased. I am very strong believer in code review. I use it in integrated training and offer it as a key service under Perl On Call.

There are several ways code review can be used as part of integrated training for your staff. The code analysis can be done via email which can be the start of a discussion thread. Another way is an interactive session with you staff (on site or telecommute) where the code and analysis are presented. The review can be discussed in detail and all of the particpants benefit from the notes and comments.

Code review is a core component of refactoring. Before you can rewrite legacy code to improve it and make it more maintainable, it needs to be properly analyzed. The review report needs to take into consideration the various goals of the refactoring project. Many questions need to be asked before the review is done. Do the API's need to be kept for legacy reasons or can they be changed? Does the code need to be faster or use less memory or have other constraints? Does it need to be more portable to other platforms? Does it need more and more complete tests?

Code review can be done at any stage in software development. Extreme programming advocates pair coding which is essentially code review during the actual original coding. Some shops have code review as part of their development process but after the coding is done. Some QA groups do code review as part of their function. And legacy code can get reviewed years after it was written.

Code review can be done by anyone with skill in the programming language. But it is best done by someone who has a strong knowledge of programming and the language in particular. Writing up a report that clearly shows ways to improve code requires good communication skills as well.

Many years ago I created a short (3 question) coding quiz that is designed to illuminate some fundamental issues about coding. You can find it in the slides of my talk "Common Sense Perl". Let me know what score you get and what you think about it.