Manas Garg Speaks

Code Review Cartoon

For those who don’t know, code reviews, as the name suggests, is going over the code you have written before you incorporate it into your product. Oh – I should have mentioned – you don’t review your own code – you get someone to review it for you. The primary purpose is to find bugs.

Though many folks look at code reviews as just another process overhead (we all write perfect code, don’t we ;), I find code reviews very intellectually satisfying.

So, when someone reviews your code, you roughly follow the following steps:

1. Ask someone to review your code
2. Get review comments
3. If no comments, either you wrote great code, or (greater chances) the reviewer did not review it very thoroughly. Consider going to step 1. If really sure, Goto step 6.
4. Discuss comments, make changes as necessary
5. Goto step 1.
6. Done!

If you are a new developer, or writing a big chunk of code, chances are that you’ll loop through this multiple times before your reviewer is completely satisfied.

As a new developer, at times people tend to take review comments personally – it’s natural. It is important to understand that code review comments are to be taken personally only if you get the same comment more than once. Code review comments are one of the best ways you can refine your coding skills. If you admire someone’s coding skills, ask them to review your code. Don’t be overly defensive – as I mentioned before – code review comments are not personal. Learn from them – and be a better developer! If you’re lucky, your reviewer will also look at the class structure instead of just the individual statements. You’ll improve upon you design skills too. And of course, you’ll introduce fewer bugs into your product.

On the other side, doing code reviews for someone is also an enriching exercise. Things when performing a code review -

1. Find bugs. Make it a fun exercise. You’ll find a bug if you look hard enough. It just has to be there :)
2. Learn from the patterns your fellow developers are using – especially true when reviewing code of experienced developers.
3. Understand components that you don’t work with on a day to day basis.

Personally, I find code reviews fun and exciting. And luckily, I have a great set of folks who do great code reviews, and give out great code to review.