Why would you want someone else to review your code?
5 reasons why we review code
As an iOS developer, I have reviewed thousands of lines of code from my peers. Like programming, reviewing code makes you feel either smart or utterly stupid.
This is because of the main issues with code reviews:
1. People don’t really know why they review code.
2. People don’t review the right things.
3. The Pull Requests are not reviewable.
In this article, we focus on why we review code. It’s part one of an article series explaining why, what and how to review code.
Five reasons why
I have asked this question to many candidates in interviews, getting a very diverse range of answers. People often review code because it’s a well-known good practice without deepening on why it’s actually a good practice.
To look at why we review code, the best question we can ask ourselves is: why would we want someone else to review our code?
Here are five reasons why:
- We want to know if the code can be understood by someone other than us.
- We want to identify other confusing areas, such as variable names, classes, methods, etc.
- We want another pair of eyes that can remind us if we forgot something (i.e. we changed a variable name at the last minute, and some design flaw became apparent).
- We want to learn from our peers if a better approach could be taken to solve the same problem.
- We made a typo and called a variable `tmoato` instead of `tomato`, so now a class that used to count vegetables seems to be summoning Mayan Gods instead.
The main flaw of why we review code
If you look carefully at the list, you might notice that there are only two items on the list that actually need more people.
This is a particularity of code reviews. In most cases, when you create a Pull Request, you are the best person to review it. You will notice typos and pretty much anything that you forgot.
Developers are not alone in this. Writers do the same.
Stephen King is known to go through three drafts before sending a novel to the publisher. From the first to the second draft, he doesn’t even ask for feedback but reviews it himself.
Does that sound familiar?
Give it a try.
Next time you create a Pull Request, review it first on your own. Then ask someone to review it. They probably will highlight valuable feedback to you, such as areas that are hard to understand or poor decisions when designing APIs.
Understanding why
When you review your own code, you can easily identify most typos, missing tests or basic mistakes. However, if you believe the word “chief” is written “chef”, you will still talk about cooks when you want to talk about leaders. Another pair of eyes can help you find the last details that polish your code.
That said, if when you review code, you only comment on the areas that someone could review on their own, you’re probably missing the point.
Code reviews are all about getting feedback, clarity and making sure what you understand can be understood by others.
What’s next?
Now that you know why we review code, we need to understand better what needs to be reviewed and how it should be done. I gave some of the answers in this article, but I’ll dig deeper while providing specific examples.
You can follow Volvo Cars Engineering if you want to receive updates on when the next article is available. By doing it, you also support many engineers to share insights and learnings.
