There seems to be an established truth in programming that code reviews find a lot of bugs. An example is chapter 18 (Modern Code Review) in the book Making Software. This is however not my experience – I rarely find outright bugs when reviewing changes. But I still think code reviews are useful. Below are my thoughts on the value of code reviews, and how to make the process efficient.

Very few bugs found. When I review code, it is quite rare that I find bugs. By bugs I mean cases where the program would do the wrong thing. I don’t count things like poor variable names, missing test cases, or misleading log messages. All those things should be corrected, but if the program ran, it would still produce the correct result. I find outright bugs maybe once or twice a year. Perhaps it is because I am bad at reviewing code. Or perhaps it is because I have really competent colleagues. Either way, it would be interesting to hear about other people’s experience in this respect.

Why code review? Even though I don’t find many bugs, it is still worthwhile. First of all, it is similar to proof reading text. It can be hard to spot your own mistakes. Therefore it is good with a second pair of eyes to check the code. Even if there aren’t any bugs, there can still be issues that should be corrected: unclear code, poor naming, missing tests etc. And once in a while there actually is a bug. Code reviews also help to spread the knowledge of how the code works.

Too late to find big problems. If I am developing a feature, and it is not obvious how or where to make the change, I like to discuss it with one or more people in the team before I start. Having a discussion like this before I start means that I will hopefully find out if there are better ways of doing it than I have thought of so far. Perhaps the change should be made somewhere else? Or maybe I could use an already existing feature I didn’t know about. If problems like these are only detected during code review, then I have wasted a lot of effort coding and testing that change.

Review, not test. Some people think that to do a proper review, you should pull down the changes and run and test the code. I think this takes too much time and effort. The original developer should test the code, otherwise how do they know that what they have developed works? Given that the code has already been tested, it is enough to review the code without also running and testing it.

Speed. One problem with code reviews is that they force you to context switch until the review is complete. The longer the review takes, the worse it is. In my team we always prioritized code reviews for this reason. You would write a message in the chat, and usually somebody in the team would start the review more or less immediately. In a team of ten people, there is usually someone that can jump in and do the code review without it interrupting their own work too much.

Ask for context. All code reviews are not created equal. Some are more complex and difficult. In those cases, it is good to talk to the developer before starting the review. They will be able to fill you in on why it is done the way it is. Sure, you can read the description in the ticket, and you can figure most things out from the code. But in my experience, it is much more efficient to first talk to the developer directly.

Criticism. When there are problems in the code, how you phrase your concerns is important. If there is a lot to complain about, I think it is nice to talk the developer if possible. First of all, you can check that you haven’t misunderstood what the change is supposed to do. If you haven’t, then it’s easier to not come across as too harsh if you have a conversation about it. But sometimes a conversation is not possible. Then I think it is good to be diplomatic in the comments. For example, instead of writing “This part should be in its own function”, you can write “Maye this part should be in its own function?”. At least in my experience, the question-comment works quite well.

Praise. When you see something good in the change, don’t be afraid to add a comment about it. It’s nice to get some acknowledgement, since most comments only point out problems.

Conclusion

What is your experience? Do you find many bugs when doing code reviews? Let me know in the comments.