Have you ever felt that code reviews can feel adversarial, like a contest of egos? The reviewer thinks things should be one way, the reviewee thinks things should be another way. Often there's no clear answer either way, but the more senior coder wins, and the other hangs their head in shame.
I wanted to briefly discuss a rule of thumb I like to use when reviewing code which I find really helps to avoid such hard feelings and makes code reviews much more cooperative than combative.
No Commands, Only Questions
It's simple. Every code review comment should be a question rather than an assertion or command. Here are some examples of how you can re-word a demand into a question:
❌ Rename this variable to aLongerVariableName!
✅ What would you think about renaming this to aLongerVariableName? Might be more easily understandable.
❌ This is too confusing: refactor it like X.
✅ Did you consider refactoring this like X? If so, why did you choose the current design over that?
❌ This is a bug, this should be like X so that it doesn't break in case Y.
✅ What would happen here in case Y? Might X be a safer approach?
Phrasing comments as questions can avoid making the reviewee feel defensive and gives them an opportunity to explain their reasoning (which might include factors the reviewer has not considered). It also gives the reviewer leeway to walk back their suggestion without being "wrong", since a question cannot be wrong. If code review comments can be phrased as questions, they become a learning opportunity (sometimes for the reviewer even) without anyone's feelings being hurt.
That's all. Again, it's a pretty simple concept, but one that I find really makes code reviews go better.
Top comments (0)