Code Review

image courtesy of pexels.com

Code review is one of those topics that I feel has always been underestimated. Most people assume that it’s as simple as just looking at your peer’s code and either approving or leaving a comment. But is there more to that?

Code review as Wikipedia would explain it is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation.

Code reviewing involves more than just looking at a person’s code. It involves acknowledging that someone else took their time to come up with a solution and needs your assistance to see if it has met the standards of a good and clean code. It’s being considerate of the effort and the thought process of your peer.

What are the benefits of code review?

1. It’s a way of sharing knowledge among your team members. I can’t tell you how many times I have learnt something new by just reviewing or even looking at someone else’s code.

2. To meet certain code standards set by the team on how to write code. It may be as simple as how you define your variable or function names. Whenever I’m writing code, I aim to make sure someone else can read it. Will they understand it without the comments? Will the function name give a clue to what it’s intended to do? These are some of the questions I ask myself when coding. This way I learn to write quality code. The most challenging thing for me, is coming up with names which make sense but practising and reading a lot is helping me to overcome this (the basic things we take for granted)

3. Lastly, A second eye from a team member can help you capture errors that you unknowingly missed.

What to do before asking for a review?

• Use code linters provided by your IDE. I use visual studio code because of the numerous extensions that it provides developers with. Most code linters will give a warning of repeated and unused variables which is useful in writing clean code.
• Check for any repeated code and try to create a util function for it.
• Look out for basic things like spacing and styling errors that can be quickly fixed.
• For complex functions, add a well-written docstring or comments that will help a review or other developers get an understanding of what it’s meant to do.
• Try as much as possible to have a function that handles only one thing.

So, how do you handle Code reviews as a reviewer?

As I mentioned earlier, reviewing requires you to be mindful of the other person’s effort and to keep in mind it’s more about the code. It should not be personal but based on how you handle Code as a team i.e do you have set standards that every member is aware of?

Here are some of the tips and approaches that have worked for me so far and I have picked from my teammates as well:

• Ask questions! Get to understand what issue the PR is solving and ask as many questions as possible. Most likely the issue or PR has a detailed explanation of the issue at hand but it does not hurt to understand your peer’s perspective.
• When reviewing, give more details on why a different approach will be preferable but before that, make sure you get a better understanding of what your team member is trying to achieve. I have come to understand the power of How do you feel if we... or Do you think we can... .These are some of the words that are considerate but can allow you to explain your point as a reviewer. It’s really important to explain why you think a certain way is better than the other. Again, don’t let it be personal!
• When suggesting a change, give code examples to your teammate. Don’t just write refactor this code.. .This shows how reluctant you are and it can probably demoralize your teammate without intending it.
• Avoid using I and you . I like reviewing code like it’s a team effort. That way I feel included in it and responsible for the changes to be made. Using weinstead makes so much sense and holds you responsible as a team member.
• Compliment! It goes a long way to building someone’s confidence. Appreciate progress and well-written code from your teammates.

These are just but a few points I have learnt along this journey. I’m sure there are more code reviewing aspects that I have missed out but I hope this will give you some perspective on how to handle code reviews the next time you have to.