A guide for reviewing code and having your code reviewed.
- Accept that many programming decisions are opinions. Discuss tradeoffs, which you prefer, and reach a resolution quickly.
- Ask questions, don't give orders. (
"What do you think about doing this that other way?"instead of"Do this that other way.") - Ask for clarification. (
"I didn't understand. Can you clarify?") - Avoid selective ownership of code. (
"mine","not mine","yours") - Avoid using terms that could be seen as referring to personal traits. (
"dumb","stupid"). - Be explicit. Remember people don't always understand your intentions online.
- Don't use
"always","never","endlessly"or"nothing". - Make a call/Talk in person if there are too many
"I didn't understand"or"Alternative solution:"comments. Post a follow-up comment summarizing the discussion.
- Don't take it personally. The review is of the code, not you.
- Be grateful for the reviewer's suggestions. (
"Good call. I'll make that change.") - Explain why the code exists. (
"It's like that because of x, y and z reasons.") - Push commits based on earlier rounds of feedback as isolated commits to the branch.
- Try to respond to every comment.
- Merge once you feel confident in the code and its impact on the project.
Understand why the code is necessary (bug, user experience, refactoring). Then:
- Communicate which ideas you feel strongly about and those you don't.
- Identify ways to simplify the code while still solving the problem.
- Seek to understand the author's perspective.
- Sign off on the pull request with a 👍 or "LGTM" comment.