

10 Best Practices for Peer Code Review - bearquality
http://www.slideshare.net/SmartBear_Software/10-best-practices-for-peer-code-review

======
dunkelheit
Good points. Can't emphasize enough the need for annotations and smallish
patches. The worst for the reviewer is a 2kloc patch touching several dozen
files without any annotations.

Positive culture is very important too. Invariably I found that the best way
to start a discussion is with a question: "why did you implement it that way?"
instead of "this code is wrong/bad/unreadable". Another mistake: starting with
trivialities such as deviations from coding style. Spotting stray tabulation
is easy, spotting a bug or suggesting better architecture is hard. Lastly,
remember that the author has got something working and your suggested changes
can introduce bugs, so this possibility should be weighted against potential
"improvement".

Giving a good code review is as hard as writing the code in the first place.

------
burkemw3
I'm not sure I agree with number 4 "Authors should annotate source code before
the review begins".

This source code will live on beyond the code review. If it requires
annotation for the code review to occur, how will it stand up when the next
dev comes along to make changes. Is the next dev expected to revisit many of
the recent code reviews including the changes?

Some context, or annotation, could be good to have in the commit message.

In most cases, I believe the changes and the code should live on their own,
without annotation.

