Code review#

Why code review?#

  • Ensure/improve code quality

  • Identify errors, bugs, edge cases

  • Ensure uniform coding style

  • Spread knowledge of the source code in the team

  • Share knowledge about programming language, techniques, solutions

Types#

  • pair programming

  • walkthrough / “looking over the shoulder”

  • software-based, e.g. commenting in Git

Best practices#

  • Keep merge requests small, don’t review too much code at a time (e.g. max. 200 lines of code)

  • Ask developer if something is unclear

  • Try to be thorough in your reviews to reduce the number of iterations

  • Communicate which ideas you feel strongly about and those you don’t

  • Identify ways to simplify the code while still solving the problem

  • Offer alternative implementations, but assume the author already considered them. Explain why you would do it differently

  • Seek to understand the author’s perspective

  • Check out the branch, and test the changes locally

  • Let the author know if changes are required following your review

How to do it#

  • Assign yourself as reviewer

  • Go to the “Changes” tab in the merge request

  • Suggestion: Change compare changes setting from “inline” to “side-by-side” (there is a button at the top right where you can change this)

  • Checkout the branch and test the changes locally

git checkout <branch-name>
  • Go through the changes in detail. Place comments directly in the line of code you want to comment. You can also comment multiple lines at once. When you make your first comment, click “Start a review”. This way, your comments are sent all at once when you are finished reviewing.

  • Add as many comments to the review as needed

  • When you are done, click “Submit review”. If you select “Approve”, this tells the developer that they can merge the MR without consulting you again. If you select “Request changes”, this tells the developer that they should re-request a review from you after they have addressed your comments.

Sources#