-
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.