Title

Chapter 6 Engaging in Code Review - as a reviewer

6.1 Learning Objectives

Learning objectives This chapter will demonstrate how to: Understand what to look for when reviewing a pull request. Provide helpful feedback in the context of code review.

6.2 Reviewer responsibilities in code review

When reviewing a pull request, you take on responsibility to ensure that the pull request is getting the project to a better state than before.

There are three aspects to reviewing we will focus on:

  1. Identify areas in the code and documentation that are opportunities for improvement.
  2. Communicate your questions and concerns effectively and in a way that creates a positive atmosphere.
  3. Determine solutions collaboratively in a way that allows for a learning as well as a long term improved product.

6.2.1 What to look for!

Depending on the goals of the project, and pull request there can be a lot to keep an eye out for. There are many articles out there about what to look for in a code review.

Here’s some general points:

  • Does the analysis answer the question it’s asking? Are the methods it uses to do so appropriate?
  • Is the code clear and readable? Does it contain a healthy amount of comments and documentation for individuals not familiar with the project to understand generally what is going on?
  • Is the code efficient with computational resources? (Are there areas it’s a bit too greedy with memory usage?)
  • Does the code stick to the style and conventions of this project?
  • Are there alternate scenarios where the current strategy might fail? (depending on the likelihood of this use case, this may be an instance for a new issue and for it to be addressed in a different pull request).

6.2.2 How to communicate it

The pull request may be the author’s precious bundle. Try to be empathetic to the learning process! You are both working on this project together – assume you both want the best out of this project. If something seems wrong, work together to find a solution, don’t ever waste time on placing blame.

Remember the author of the pull request has been putting time and effort into this! This cartoon shows a stick person cradling a computer with code on it with lots of hearts and love swirling around. The pull request may be the author’s precious bundle. Try to be empathetic to the learning process!

Remember that everything sounds harsher when you don’t have in-person cues! In this example, Avi may be stating factual things, but without his pleasant and reassuring disposition, it can feel super harsh.

Ruby requested a code review from Avi who has responded: This code needs work. Don’t use the formattR package it’s inefficient and takes forever to run. You didn’t style the last chunk of code. This feels very harsh to Ruby who has a single tear.

If Avi had reframed his comments, they might be more effective in this collaboration. Babatunde (2018) suggests framing review comments in three ways to help communication: questions, suggestions, and appreciations.

6.2.2.1 Questions

For example:

What happens if this doesn’t get saved? Does it throw an exception or fails silently?

The key is to be specific with the questions. Mention exact file names. Put comments on the line you are referring to. Explain what you think is happening and ask them to explain if that is correct.

6.2.2.2 Suggestions

For example:

I suggest you use an ArrayHelper getValue method here because of its error handling capability instead of accessing the value directly You could even go further by giving an example: $a = $b[‘key’]; would raise an error if key is not set but \(a = ArrayHelper::getValue(\)b, ‘key’); would return a null value if key is not set.

Giving suggestions and explain not only how to implement it but why it might be preferred in this scenario is a great learning process both for the author and yourself.

6.2.2.3 Appreciations

Start every review comment with an appreciation for the hard work completed! This goes a long way for creating a positive atmosphere.

For example:

Nice Job! Alice. I suggest we create an interface for this service so other substitute services can implement the interface as well, this would enable us change to a different service with very minimal efforts when the need arises. What do you think?

Let’s see how Avi’s message could have been reworked to give a more effective review:

Ruby has requested a review from Avi but alternatively, Avi has framed his review in a more effective manner, giving context, examples, and creating a much more positive collaboration. Avi’s review says: Ruby, thanks for all this work! This is a great start! I have a few questions so we can further polish this code. Is your usage of the formattR package because of the weird formatting of the data.tsv file? Perhaps we can brainstorm another approach to this that would allow us to get rid of this package requirement. I think that in your last chunk you may have forgotten to style the code according to the conventions for this repository. Perhaps we can discuss how we introduce something to help all authors of this repository adhere to the conventions. This may be an instance we can use automation or a checklist to help. Ruby happily accepts this review and the collaboration will create a better product.

This interaction reminds us that effective code review is steeped in empathy from both sides. Authors need to appreciate the time and effort the reviewer is spending to help them; while reviewers need to be sensitive to the amount of effort put in by the author already.

Empathy is an important part of effective code review!

6.2.3 Exercise: Review Past you’s code

  1. Find the oldest code you wrote and currently have on your computer.
  2. Create a repository and pull request with this old code, following the general steps for creating a repository and pull request from the previous chapter.
  3. Request yourself as a reviewer.
  4. Review the code on Github using their docs as a guide for the mechanics of it.
  5. As you review, have empathy for past yourself, and give questions, appreciations, and suggestions in regards to this code.

References

Babatunde, Otaru. 2018. “Comments During Code Reviews.” PullRequest. https://medium.com/@otarutunde/comments-during-code-reviews-2cb7791e1ac7.
Duretti Hirpa, Mark Christian. 2016. “On Empathy and Pull Requests.” Slack. https://slack.engineering/on-empathy-pull-requests/.
Hauer, Philipp. 2018. “Code Review Guidelines for Humans.” Philipp Hauer’s Blog. https://phauer.com/2018/code-review-guidelines/.
Hildebr, Mischa. 2020. “Your Code Sucks! – Code Review Best Practices.” QuickBird Studios Blog. https://quickbirdstudios.com/blog/code-review-best-practices-guidelines/.
All illustrations CC-BY. All other materials CC-BY unless noted otherwise.