Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

August 6th, 2009 at 5:39 am

5 tips to make good code reviews

with 16 comments

Code reviews are one of the most valuable engineering practices.

  1. Code reviews improve the quality of the code through the suggestions from the code reviewer.
  2. Code reviews are a great tool to indirectly teach other developers parts of the system they may have to maintain in the future.
  3. Code reviews encourage people to learn best practices from other developers.
  4. Code reviews can be used as a validation of the clarity and simplicity of the system.

You may have noticed that I have omitted from the list that code reviews help finding bugs and enforce coding standards and that’s because:

  1. Code reviews SHOULD’T be performed to find errors in the code.
  2. Code reviews SHOULD’T be performed to enforce coding standards.

10 years ago these previous two points would have made sense in your code reviews, but not anymore, this should be covered by your automated tests and by some tool which should enforce your coding standards. All this said, it doesn’t mean that is bad to raise a bug or a coding standard defect in a code review, it means that to found them is not the purpose of the code review.

From this perspective then, these are my five tips to make good code reviews.

1.- Make your code reviews often.

I have suffered in my own experience from late code reviews, I used to work in a company where a huge code review of the application was supposed to be the last stage of the development, and they were simply useless, having late code reviews have the following disadvantages.

  • The more code to review, the more likely that the developer won’t accept a suggestion of refactoring.
  • The longer since the developer coded, the more likely that the developer is personally attached to the code. I would like to remind here one of the biggest problems of software developers, their ego, if a developer designs something and makes it work, no matter how crappy it is, there are a lot of chances that his ego will interfere with any suggestion to improve the design.
  • The closer to release date, the less importance is given to enhancements to the code.

My own approach is to make code reviews every time I have just finished coding something non trivial, and that usually means several times a day.

2.- Make your code reviews informal and short.

Forget about checklist, turn around and ask for 5 minutes of attention to any colleague you have beside, if you have a checklist, either one of this 2 things will happen.

  1. Only what is in the checklist will be reviewed during the code review.
  2. Code reviews will become formalities, the people will sit together for as short time as possible and will just pretend that they care about the code.

Having short and informal reviews will help you to engage in open conversations where no one will feel as if they were reviewed, but advised.

3.- Make your code reviews with different reviewers.

Is a good idea, if possible, to not use always the same person as code reviewer, there are three main reasons to look for different reviewers every time you want to review your code.

  1. Is good to get different perspectives
  2. More people will be able to maintain your code in the future.
  3. It is a team building activity.

4.- Keep a positive attitude.

Again, remember one of the worst problems of the developers, their ego, having a positive attitude will help to make the code review much more pleasant, and all participants will be more likely to accept the suggestions, and remember: you are not the code!

5.- Learn to enjoy the code reviews.

This is the most important tip, if you are in a team where people enjoy code reviews, you will enter in a dynamic where everyone will be committed to deliver quality code that not only looks good to them, but to the whole team.

16 Responses to '5 tips to make good code reviews'

Subscribe to comments with RSS or TrackBack to '5 tips to make good code reviews'.

  1. If you don’t have bug hunting as an explicit output you’ll have a tough time selling your PHB on the need to allocate time (==money) to code review.

    Josef

    20 Aug 09 at 4:05 am

  2. Very nice article.

    Jef Claes

    20 Aug 09 at 4:32 am

  3. The way I see peer reviews is that you don’t need to ask your boss permission to perform them, you just naturally use 5 to 10 minutes to sit down with a fellow programmer that is curious to know what do you think of his/her code

    Alberto Gutierrez

    20 Aug 09 at 5:29 am

  4. Hello Alberto, I have translated in french your excellent post : 5 conseils pour mener de bonnes revues de code. Regards, Fabrice.

    Fabrice Aimetti

    20 Aug 09 at 7:24 am

  5. Thanks for that Fabrice!!! I appreciate it very much!!

    Alberto Gutierrez

    20 Aug 09 at 7:49 am

  6. [...] 5 tips to make good code reviews | Making Good Software http://www.makinggoodsoftware.com/2009/08/ – view page – cached , Code reviews are one of the most valuable engineering practices. Code reviews improve the quality of the code through the suggestions from the code — From the page [...]

  7. [...] 5 tips to make good code reviews Making Good Software (tags: agile programming) [...]

  8. All good advice, but I’m having a bit of trouble believing that finding errors in the code can always be ” covered by your automated tests.”

    At the very least, it seems the automated test code should be reviewed in order to make sure that *it* is correct. No static analysis tool can detect whether the software really solves the problem it was intended to solve.

    Gregg Sporar

    22 Aug 09 at 10:26 am

  9. You are actually making a very good point here Gregg, I agree with you 100%, automated tests will NEVER cover 100% of your bugs, that’s why, as you say, you also need to review your automated code as well. good observation!

    Alberto Gutierrez

    22 Aug 09 at 5:16 pm

  10. [...] 5 tips to make good code reviews — Code reviews are one of the most valuable engineering practices. [...]

  11. [...] 5 tips to make good code reviews [...]

  12. [...] 5 tips to make good code reviews [...]

  13. [...] Making good software – Alberto Gutierrez 5 tips to make good code reviews Test obsessed – Elisabeth Hendrickson The wordCount simulation utest.com official blog Testing the limits TestMechanics – Jitendra Kapoor Becoming an indispensable tester [...]

  14. Nice article. I would add that formal audits need to be done too, but not as frequently as informal audits.

    Design best practices and coding standards should be part of checklist – automated tools will only go so far.

    Kashif Baig

    29 May 10 at 8:30 am

  15. Josef,

    If you need to sign-off five minutes’ code review time with higher management, you have a micro-management problem in your company.

    Tomalak Geret'kal

    31 May 11 at 2:53 am

  16. [...] training. Probably the two easiest ways to help a programmer understand if some code is done are peer reviews and [...]

Leave a Reply