Tuesday, 22 March 2011

Why I like code reviews

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.


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.

Thursday, 17 March 2011

Why blog?

Why blog? Is this what everyone's first post is about? Probably. What's the point? Will anyone read it? All questions I imagine people consider.

For me the greatest benefit is that the process of writing something down helps clarify it. When something floats around in my head there's always gaps, things I haven't thought of or things I believe I understand but actually don't. At some point while transferring the information from my brain to the computer these gaps become apparent. This encourages me to research the aspects I've missed or not understood. I am also one of those people who learns best by explaining a problem to others. So blogging in this way hopefully will increase my understanding of the subject I blog about and increase the chances that I will retain the information. Double win! On the other hand I may just rant about some stuff nobody cares about.

You never know, I may actually get better at writing too. It has never been my forté. Mostly writing is a painful, slow process and I'm rarely happy with the end result. Does it make sense? Is it logical? Have I got my points across? Is there any point blogging about subjects that considerably more intelligent people have already covered? Do I sound like an idiot? Probably. Ahhh sod it, practice makes perfect. It's good to get outside your comfort zone now and again. Hopefully, after some practice, it will increase my communication skills; my thoughts will tip out of my brain in a more logical fashion and I won't have to rewrite each post several times (this post has been rewritten at least three times).