Code reviews – how to approach them

We do it (almost) every day, we review someone else’s code and our code is being reviewed by our colleagues. It might be a bit tricky for junior developers to get used to it at the beginning though. Let’s write down some useful tips about code reviews.

  1. We do it to improve a codebase.

    A main purpose of a code review is to get a feedback on your code from a colleague from the team. The is no developer who writes perfect code, we all sometimes miss something, forget to test some edge case or commit some unneeded code. This is why code review is helpful – you get someone else looking at the same code, someone who approaches code in a bit different way, who tests different cases, someone who didn’t spend on your branch 4 last days and looks at it with a fresh mind.

  2. Try to teach, not blame.

    Blaming someone because of not perfect (in your opinion) code doesn’t help anyone. It destroys that code author’s day, it destroys your day too. Try to phrase your comments in a way you would like to get feedback too, the way it can be useful, full of knowledge. I think it often sounds nicer when you use plural form rather than a singular one while requesting some changes: for example “Can we move it to a class level?” rather than “Can you move it to a class level?”. It shows that the author of the code is not left alone, that you are trying to improve this code with them.

  3. Link documentation pages, blog posts.

    Different developers have different opinions how particular code could be improved, changed. There are many cases when it’s just subjective, there are a few different opinions and none of them is the only “right” one. On the other hand, there are certain well known patterns, that experienced developers just use automatically. Less experienced developers might not know about them. While trying to suggest such options try to give a link to documentation page, blog post or similar. It may have one nice side effect – author of the code may save this link in their notes, keep it for the future and learn quicker.

I think I will conclude the post at this point. Feel free to add your own tips in comments. Happy code-reviewing 🙂