Code reviews are thought to be painful by many, but in my opinion that can be
avoided. Code reviews can be a great tool for a project to help keep the code
clean and concise.
Last time I talked about Code Reviews and how to make them successful, this time I thought I would spell
out some of the Rules of the Game.
- Critique the Code, not the Coder
This is the most
important rule for performing code reviews. The purpose of the code review is
to review the code, not review the coder. Keep everything on the positive. If
there is something in the code that is not right, make sure you speak only about
the code. It is also nice to give praise when you find something good, this can
go a long way as well.
- Check ego's at the door
Code reviews are not the time to
try to demonstrate who the better coder is. Actually, there is really never a
valid time to do this, but this is especially not the time.
important that 'junior' level coders feel comfortable during the review and this
cannot happen if they feel like they are being belittled or looked down upon in
the review. This will also allow for a more open communication and will lead to
- Follow up on any changes
During most code reviews there
will be something found that needs to be changed/updated/removed/fixed/etc.
Make sure that these get noted. A buddy of mine likes to leave TODO's in the
code with the date and the change needed. I live this approach because you can
easily search for these and fix them.
It is important to not only mark
the changes, but to follow up to ensure the changes have actual been made. I
would suggest that the first 5 minutes of any code review be spent reviewing the
'TODO's' from the prior code review session.
- Submit your code to reviewed prior to the review
order to keep the code review short and sweet it is best to send over the code
to be reviewed before hand. This also allows the reviewers to be familiar with
the code. If you have any design docs or business docs, send them over as
If the reviewer of the code is familiar with the code before the
actual review they will be able to ask more intelligent questions and should be
able to speak to more about the design of the code. As one commenter said
'doing a code review without understanding / approving of the design of the
code is bad. The code review will end up devolving into "you forgot comments
here", "you used the wrong parameter naming convention here", etc. Those are
valid points for a code review, but they don’t really get to the heart of what
you’re trying to accomplish with a code review.'
- Keep the review short and sweet
Try to stick to a 30
minute time limit for the reviews. Keeping the review short and sweet will
accomplish a few different things.
1) Will keep everyone on track with
the task at hand.
2) Allow for a more productive meeting.
3) Will allow
for more reviews, if they only take 30 minutes then you can do them monthly
- Create your own Rules for the Review, what are you looking
Before you even have the initial code review, there needs to be
your own rules or check list as to what is to be accomplished during a code
review. This will allow the author of the code to know what to expect before
the actual review as well as keep all the reviews consistent. The worst thing
that could happen would be for each review to be different because then no one
would know what to expect and the usefulness of the reviews is out the
Potential Rules for the code reviews (in no given order)
the code following coding standards?
2) Is the solution solved by the
simplest means possible?
3) Are there unit test for your code?
4) Are the
proper/valid comments about the intent?
5) Did you solve the actual business
6) .... etc
- Ask questions to the coder, don't make judgements
during the review there is some code that is questionable make sure to ask the
author questions rather then make judgements or statements. By asking a
question, you will avoid a defensive response from the author. This can help
relax the author and can often times open their mind and allow them to see your
Even though you are asking questions, and not making
judgements during the review. Stay mindful to not ask the 'Why Did You Do
This?' question. It is ok ask what the intent was for the code, but make sure
to phase it in a positive light.
- Understand that there is more then one way to solve a
Software development is pretty unique in a lot of ways and
one of them is that there are many ways to solve a common problem. Some better
then others, but still many ways. If the author of the code chose a way that is
different, that is fine. The goal is to make sure the code is quality and
maintainable. If this solution is solid and the code is of good quality move
If these rules are followed, code reviews can be relatively painless and
very, very successful.
06-12-2007 8:41 AM