How to lead a code review

Code reviews are expensive. Time spent reviewing code by managers and peers is time spent not programming. So if you're going to do code reviews, it makes sense to do them well. That's true of the process itself (see ) and the during the review.

But the first order of business is to identify who should lead the code review, and who else ought to participate in the code's evaluation. The first answer is fairly clear, but as you'll see, developers have wide-ranging opinions about the second.

Straight-up: the person running the code review needs to be and ideally a warm and supportive leader. Micheal Lalande, director of technology at QLogitek, says, "Peer reviews are great, but if the people doing the review are less competent than the person doing the coding, there is little to no value other than possibly training a less experienced developer."

Expertise is important, whether it comes from managerial responsibility (i.e. the project lead) or the subject matter of the code being examined. "The best code reviews were ones where the code reviewer was , well known in that particular area of development," says Lalande. "They worked closely with the development team to ensure they understand the context within which the software had been developed, and can work with the developers to understand why particular development decisions were made."

In addition to the leader being a senior engineer, she must be given authority to do code reviews from the engineering department head (Director or VP), says Christopher Buchino, director of software engineering at GotVMail Communications. "This person should have intimate knowledge of established coding standards as well as a mastery of software development best practices."

Another thing to look for, says Tim Rosenblatt, the Agile development director at , is someone who has seen many different coding styles. "There are a lot of people who write code very well, but will be overly (and unnecessarily) critical of code that has a different style from their own," he points out. "It's good for the reviewer to be able to objectively explain why the advice they are giving is correct. Different projects may have different requirements, so having an objective explanation helps you decide if the advice fits in with the project requirements."