Rules for My Code to Be Reviewed

I’ve read a post How to Make Your Code Reviewer Fall in Love with You and found some rules for myself.

One rule to rules all rules.

Value your reviewer’s time.

Rule 1

Review my code first before sending request to my teammates. And do not just check mistakes, imagine that I’m reading it the first time and what might lead myself into a muddle.

Rule 2

Write a clear changelist description. A good changelist explains what the change achieves and why they should be changed. Remember that the changelist is not just for my teammates, they might be read by my followers in the future, or by my partners through our promotion. Thus, the changelist should summarize any background knowledge the reader needs.

Rule 3

Answer questions with the code itself. When my reviewer expresses confusion about how the code works, the solution isn’t to explain it to that one person, but explain it to everyone.

Rule 5

Narrowly scope changes. The best changelist just do one thing. The smaller and simpler the change, the easier it is for the reviewer to keel all the context in their head.

Last but not least, a reviewer generates high-quality feedback when they can focus on the really interesting parts of my code. If they are bothered by my simple mistakes, I suffer them too.

And remember that communication via words could be frighteningly easy for simple misunderstanding or thoughtless commments. Emotions run hot when critiquing someone else’s work. so be conscious of pitfalls that could make my reviewers feel attacked or disrespected.