10 commandments of code review

For the author

  1. You shall make unitary merge request. 🔢 Your merge request should introduce one change and be of a reasonable size.
  2. You shall describe what your code is doing from a high level perspective. ✏️ You should give enough context and elements to the reviewer so that they understand what you are trying to achieve.
  3. You shall assign several reviewers. 👪 The more reviewers you have, the more bugs can be raised.
  4. You shall answer all remarks of reviewers. ✅ All remarks have their importance and should be addressed. When answering the remarks, keep in mind that nothing is obvious for the interlocutor.
  5. You shall not take things personally. ❤️ It’s always a good thing for a team to confront ideas.

For the reviewer

  1. You shall code review everyday. ⏰ Code review is good for communication and knowledge sharing.
  2. You shall read the merge request description before jumping to the code. 📖 You first need to understand what the author is trying to change and then check if the change is properly implemented.
  3. You shall be accurate and use complete sentences. 🔊 The author should not be guessing what you are trying to say. When doing remarks, keep in mind that nothing is obvious for the interlocutor.
  4. You shall be kind. 👼 “This variable must be renamed userId” vs “What about renaming this variable to be consistent with other variables?”
  5. You shall use the OIS-rule. 📏 Observe-Impact-Suggest. Observe: “This method has 100 lines”. Impact: “It’s complicated for me to understand its logic”. Suggest: “You can extract it into 2 methods with explicit names”.