Avoiding Toxicity in Code Reviews
Modified 2023-10-24
Don't claim opinion as fact
The claims need to be backed up by citing documentation, community guidelines, code examples, ... The comments which can be caught by linting, checking or testing the code don't belong in the code review and should be formalized with automation to prevent an avalanche of unhelpful comments.
Don't ask to solve issue in passing by
It shouldn't be discouraged to refactor code, while working on features, because that's how you avoid accumulation of a huge technical debt. However, it's extremely rude to request changes that are not part of the original feature request as the person might not have the time to spend on fixing unrelated issues.
Don't ask judgmental questions
- Why didn't you do _ here?
- Why didn't you pull the translations in this file?
Use questions to drive collaboration instead, or recommend another way. The judgmental questions don't help anyone and makes the contributor feel dumb.
- What do you think of pulling these translation into a constant file?
Don't ignore comments
Getting ghosted always feels bad, and as code reviewer I'd less inclined to go the extra mile if you don't end up responding to the comments. If you plan on tackling a comment in a different PR, or opening a ticket for it, so it doesn't get lost, communicate that!
Don't feign surprise
- Did you test the code before you checked it in?
Everyone has gaps in their knowledge and code reviews are a great way to help fill those gaps by learning from other developers. Don't make people feel bad for not knowing the exact same thing you do, because chances are they will teach you something in the future.
- This breaks when entering a negative number. Can you address it?
Don't show-off, but teach
Is your comment really helping the person? Teach them something? Or is it purely nitpicking to show-off your knowledge and skill?
Metadata
- Creator(s)
Sandya Sankarram
Be better when reviewing other people's code.