A while ago one of my colleagues suggested we started using Kiln. If you haven't heard of Kiln, check it out now, it's a version control system build on top of Mercurial. I really cannot recommend Kiln, and the associated bug tracking software FogBugz, highly enough. Anyway, I was initially dubious, what was the point I thought. The main advantage of using Kiln, as I saw it, was to allow easy code reviewing. But what's the point in a code review? We've got on okay without them for a long time, why should we bother now? It's just a massive waste of time. Turns out I was wrong.
The obvious - fixing bugs
I fire off my first code review to a couple of colleagues. It comes back some time later with a few comments, "Have you considered this scenario?", "Does your code allow for the following?". Errrmmm...no I didn't think of that, it'll fall over if the user does that particular operation. Hurray! For whatever reason my colleagues have spotted some bugs in my code that I missed. This is a very good thing. The sooner bugs are found the less they cost to fix, plus I avoid the embarrassment of having my code causing a problem in the live environment. Double win.
A learning tool
It's not just finding bugs that makes code reviews useful. Having eyes on other programmers code can introduce you to methods you didn't realised existed, or techniques you have never used or maybe a simplification of a process that had never occurred to you. The examples are endless. The bottom line is that people think differently and have different areas of expertise, so looking at others code is a good way to learn. Anything that increases the amount of knowledge you can pick up from colleagues sounds good to me.
Increase code quality
Have you got any bad coding habits? Do you sometimes forget to add meaningful comments where they would be useful? Do you occasionally give a variable a stupid name like x, or myVariable or someData? Ever written some code which makes perfect sense to you and nobody else? Well I hope the team you work with are picky because if they are, and you do code reviews, your code will improve. It will become more consistent and more readable.
Increase awareness
My team used to have a weekly meeting. In that meeting we took turns briefing everyone else on what we'd been doing during the week. What a snorefest. I tended to lose interest and drift off about halfway through. Now there is no need for this boring and pointless practice. A piece of work is finished, a code review is created, everyone can see exactly what code was changed and see the case explaining what needed to be done (thanks Kiln and FogBuz). All that, and it can be done in your own time without leaving your desk. Has routine been written which you could use in the future? Now you know. Has some code been moved so it's in a more logical place. Now you know. Happy days.
Another advantage is that you get more eyes on each piece of code. This is particularly useful if one team member was written all the code for a specific feature, or if a colleague leaves. Even if each reviewer only looks at new code for five minutes it won't be completely alien the next time they have to take a peek.
Difficulties
I've found that peer reviewing code requires a certain level of commitment. There's little point completing a review a week after the work was completed. Jimmy won't thank you for picking holes in his code now he's working on something else and completely forgotten the work you have reviewed. Better late than never? Only just, it's much easier all round if the reviews are done quickly. Of course I'm speaking from personal experience, if your work flow enforces code reviews or your boss enforces code reviews then they'll get done, otherwise if you're not careful they'll fall by the wayside.
Consistency is also key. If I continue to make the same errors in my code, my colleagues must continue to point them out. It does me no favours it they let it go after the third or fourth time. Eventually I'll stop making the mistakes and the quality of my work will improve. If everyone does this, regardless of how annoying it may be to correct small things, the overall quality of the code will improve.
In conclusion
As you can probably tell now I'm a convert to code reviews, I feel they're a vital part of my day to day work.
