Translations:Guidelines for a healthy code review culture/21/en


 * Automate: Everything you automate is no longer a burden during code review. Automate as much as you can, and note repeated discussions as potential opportunities for automation.
 * Aim for clarity: Be clear about what you consider a blocker as opposed to a matter of preference or a request for clarification. Avoid euphemisms and incomplete sentences: clearly state what you mean and what you think needs to happen. Make it clear how conflicts will be resolved.
 * Keep patches small: Large patches are difficult to review and may languish in code review for too long. Authors should submit small patches, but reviewers should also avoid asking for unrelated work in a patch and should err on the side of resolving issues later when possible. Big picture or architectural discussions should happen elsewhere.
 * …but provide helpful review: Not enough feedback is a problem, too. Cursory reviews don’t spark discussion or foster education. If sufficient reviews aren’t happening, consider why: is it a question of resourcing, social dynamics, or something else?
 * Avoid nitpicking: Most nitpicks are unnecessary to the ultimate goal. Follow this process:
 * For any comment, ask yourself if it’s a nitpick.
 * If it is, consider deleting it.
 * If you must nitpick, label the comment as such and make it non-blocking.
 * Consider whether that nitpick could have been identified via tooling.
 * Respond quickly: Critical feedback goes over better if it’s provided promptly and followed up with quick responses to questions or updated code.