Member-only story
10 Tips To Write Effective Code Reviews
7. Be humble and positive
We have all seen those code reviews where the code keeps going back and forth and it takes several iterations until it finally gets merged.
It is not only annoying for the author that the review won’t accept the code, but it is also annoying for the reviewer who will be thinking that the author just doesn’t “get it”.
Some good news though; it is not only up to the author of the changes that the feedback is received smoothly and the process goes faster. There are also some good practices the reviewer can deploy ensuring a less dull and more clear review process.
Effective code reviews are a win for everybody, because:
- The author will understand your feedback more clearly, resulting in fewer iterations of the code changes.
- You will be providing the author with tips and points to consider which will affect their approach to the codebase as a whole, so there will be fewer “mistakes” in the next one.
- The work will be merged more quickly, unblocking potential others.
- At the very least you will have a quality discussion about an implementation choice.
Note that this article doesn’t explain how to conduct a code review or what to pay attention to while doing so. Instead, we list here some tips and rules of thumb to your approach and behavior regarding the review process. So if you already review code regularly in your work, this article is aimed to help you reconsider some of your practices and become a better reviewer.
Let’s get to it.
1. Always Say Why
Let’s look at some potential review comments:
bad function name
this shouldn't be here
I think this might break
There are some things wrong with these comments, but the most prominent issue is that they don’t provide reasoning. From these comments, the author of the code can only assume what is wrong with their code, and we all know how assumptions are bad — specifically in this case;
- The author might arrive at a wrong conclusion about why their naming/code…
