Agree on a consistent style guide and let formatters handle the checking. Style is subjective and offers little value unless it is consistent. By agreeing on a style guide and using formatters for consistency, code reviews can focus on functionality and purpose rather than style.
Instead of instructing the author on what to do, provide specific examples or code. Examples help avoid misunderstandings and make it easier to understand, accept, and implement the requested changes.
Phrase your feedback to minimize the risk of raising your teammate’s defenses. Make it clear that you are critiquing the code, not the coder. Using ‘you’ increases the risk that the recipient will take your criticism personally. Consider using ‘we’ to emphasize shared code ownership.
Requests make it easier for the author to respond politely. They may have valid reasons for their choices. Framing your feedback as a command can make any pushback seem like disobedience. Framing it as a request or question allows the author to respond more openly.
Explain both your suggested changes and the reasons behind them. Grounding your notes in principles frames the discussion constructively. Provide supporting evidence, such as links, so the author can learn more about the principle if they are unfamiliar with it.
While it is tempting to explore every opportunity to improve the code, the author's patience is finite and may wear thin. They could become frustrated if you withhold approval for too long while you keep finding new ways to improve the code. This can slow down the process and may not be the best use of your resources. Focus on the important issues. See Parkinson's law of triviality.
To keep reviews and changes manageable, avoid reviewing code that is outside the scope of the current change. Grant approval as soon as possible. Do not withhold approval for minor changes, and trust that the author will incorporate your feedback if they agree. Avoid being the last gatekeeper who enforces code quality strictly, as there will be times when you cannot be present or others will handle the review.
Use full sentences to express your suggestions and provide necessary details and context. This approach is more respectful and helps others join the discussion easily and understand your arguments better. It also allows them to make informed decisions.
Instead of requesting open-ended changes like “Add more tests,” specify what exactly can be improved or what is missing, so the author does not have to guess. Ideally, offer examples (see above).
Invest the author's and reviewers' resources in issues worth solving. This prevents frustration and allows you to deliver value more quickly. If you believe something is worth changing, avoid labeling your feedback as a "nitpick."
If there are too many issues or excessive back-and-forth in written communication, switch to face-to-face communication. Cooperation, finding solutions, and reaching common understanding and compromises are usually more efficient this way.