• Let computers do the boring parts: automatically verify that the code builds, tests pass, code matches team style and has no unused imports or unused variables.

• Settle style arguments with a style guide.

• Start reviewing immediately, ideally within minutes. Treat code reviews as a high priority. The absolute maximum turnaround on a review round should be one business day.

• Start high level and work your way down. Keep the number of notes below 20.

• Be generous with code examples. Lighten the author’s load by writing out some of the changes you’re suggesting.

• Never say “you”. Drop or replace with “we”.

• Frame feedback as requests, not commands.

• Tie notes to principles, not opinions. See SOLID.

• Aim to bring the code up a letter grade or two. Not F -> A, but E -> C.

• Limit feedback on repeated patterns.

• Respect the scope of the review. If the changelist doesn’t touch the line, it’s most likely out of scope.

• Look for opportunities to split up large reviews. No reviews greater than 400 lines of code. Suggest ways to split.

• Offer sincere praise. Give positive feedback as well.

• Grant approval when remaining fixes are trivial.

• Handle stalemates proactively: talk it out, consider a design review, concede or escalate.

Checkout the full publication by Michael Lynch: part1, part2.