Page 97 -

reader) does not understand what the code does or disagrees with the interpretation, the
author of the code explains what it is the code is supposed to accomplish. Sometimes the
team can suggest a better, more self-explanatory way to accomplish the same thing; often
it is simply a matter of explaining the purpose of the code to the person who raised the
issue. If any inspectors found a defect in that block of code, the issue is raised and the team
either comes up with a fix on the spot or tags it as an open issue for the programmer to fix
later. The moderator then updates the inspection log, and the inspection continues until
the reader completes the code sample being inspected.
Another important difference between code reviews and document inspections is that the
code review is much more focused on detecting defects, and less on fixing them. This is
because many defects in documents can be corrected with one or two sentences, or with a
change in wording. Defects in the code can be much more involved, and there are often
many ways that they could be fixed. The discussion of each defect is longer in a code
review than it is during an inspection, and there are usually many open issues at the end
of the code review.

In the code review, the moderator needs to be especially careful not to let the meeting
turn into a problem-solving session. Programmers love to solve problems. It’s easy for
them to get caught up in a small detail and turn the meeting into an analysis of a minute
problem that covers just a few lines of code. However, long discussions like this will pre-
vent significant amounts of code from being reviewed. That’s not to say that these discus-
sions are not valuable—they just don’t belong in the code review meeting. If a discussion
looks like it will take more than three minutes or so, the moderator should stop the dis-
cussion and add it to the inspection log as an open issue. There should be few open issues,
however, because most code defects should be straightforward to describe and document
once they have been identified.

There are effective ways to modify the code during the review. Many inspectors have
found that it is very helpful to refactor the code during the review. By applying refactor-
ings on the spot, the team can make the code much more readable and identify additional
defects. (See Chapter 7 for more information on refactoring.)
After the inspection meeting, the code author performs the rework and closes the open

issues, and the moderator follows up with each of the inspectors and gains their approval.
Instead of getting formal sign-off with physical signatures, it is usually sufficient to indi-
cate the approval in the log comments when the changes are committed to the version
control system (see Chapter 7 for more information on version control).
There are several additional benefits for the code review. One is that people learn how
their teammates think about the code. A good way to encourage this is to switch off code
readers in each review, so every team member gets a chance to be a reader. Reading code
aloud and explaining it helps programmers think through problems. Every programmer
should be able to explain his ideas well; discussing code during a code review is good prac-
tice for that.

REVIEWS 89