Code reviews are something that not all of us like or do, but they can be
very valuable. I thought I would express some of my thoughts/opinions about the
benefits and pit falls of performing code reviews.
Benefits of Code Reviews
Performing regular and
consistent code can have a great impact on your project. Some of the benefits
- Keeps code clean, can help enforce coding standards
of the great benefits of a code review it to allow the code base as a whole to
maintain standards. Along with maintaining standards, knowing your code is
going to be reviewed will undoubtedly encourage the coder to write
better/cleaner code. Maybe they means adding a few comments where they would
not have otherwise. Maybe it means they will rethink their logic in order to
make it cleaner, more readable.
All of this makes the code base better
for future maintenance/expendability.
- Forces/enables outside options on your
Another positive that come from code reviews is that
it will allow other team members to possibly come up with alternative ways to
solve your coding problem. This can be useful because maybe there is a simpler
way to solve the problem and you did not see it. As we know, Simpler is
- Helps spread knowledge on code
By having other people
look over your code as well as having the intent explained to them, you are
spreading the knowledge of your code. This knowledge may only be in terms of
intent, but the more people who understand the code base as a whole, the
better. You could also achieve this result with paring, but that is not the
topic of this post
Possible Pitfalls of Code Reviews
Unfortunately there are
a few pitfalls to code reviews. Although in my opinion these are small, and
most definitely can be avoided, you do have to give them thought. Some of these
- Feelings get hurt
The first rules to performing a code
review is to Critique the Code, not the Coder. NEVER, EVER, EVER attack the
coder, only critique (not slam) the code. If for some reason the developer of
the code feels they are under attack they will go into defense mode and start
defending their code from the wrong angle.
If this happens they will
not hear ANY of the positives about the code, only the negative. At this point
all is lost, better off stopping the review and starting over later.
- Nothing of value comes out of the review
If during the
code review change requests are made, make sure they are acted upon. If these
requests are never acted upon and the pattern of this starts, the code review
process is simply a waste of time. The developer will learn that they don't
'have' to make changes and they will not.
Make sure to perform the
follow up later by just looking for the changes, or actually start off the next
code review by revisiting the old code to ensure the changes were made.
- Too much time is spent on the review
Code reviews should
be short and sweet, 30 minutes tops. If your review extends past 30 minutes,
you are probably reviewing too much code.
By extending the review you
will at some point start to lose focus. When this happens the value of the code
review starts to diminish.
Conducting Code Reviews
In order to perform quality code
review there needs to Rules of the Game (hmm, sounds like the next post idea).
Without these rules, the review could get personal and this will not accomplish
- Performed on a regular basis
Code reviews need to be
conducted on a regular basis. This can be weekly, once a month, once a quarter,
what ever, just so that they are regular.
- Keep the group small
Keep the group performing the
review small. Maybe 2-3 'outside' people and the author(s) of the code being
reviewed. This will allow for the meeting to be shorter and more effective. A
large group will just cause process to drag on.
With keeping the group
small, you can also create consistency with who is performing the review. This
consistency will lead to better results.
- Know what you are looking form
Before you start the
review, communicate the what is being looked for and what is be expected during
the review. This will allow everyone to be on the same page and allow for
better results. Besides, open communication can go a LONG way.
Every code review should be as consistent as
possible. Make sure that the rules don't change from one review to the next.
Also make sure that what you are looking for does not change. If in one review
you are looking only at logic and disregarding coding standards, the developer
will come to expect that next time. When the next time comes around and you
don't look at logic, only standards the developer will be confused and possible
These are just some of my thoughts on Code Reviews, would love to hear
Till next time
06-11-2007 9:08 AM