“Anybody can write code if he learns programming. But what makes him stand out of the crowd is the quality of the code”. Yes, the way you write and construct the code defines you as developer. Before anything else, how many of us feel to read another person’s code? How do we feel looking into our own code post 6 months ? There might be some suggestions that pops in our mind like, “Oh! I would have written like this/that”, which you would have never thought during coding that piece of code. Likewise, there may be some suggestions by our peers that could improve your code, which people name it as “Code review”. People often fail to understand the purpose of code review. We have cultivated a habit of code review as nitpicking. Ofcourse, it is partly yes! But the main purpose according to me is to share the knowledge and enhance the quality. Let’s dig deeper into it.
I still remember the first time when I was given an opportunity to review a code. I didn’t have a clear checklist or flow to review a code. But I had a few vague points(do’s and don’ts) which I learnt through the experiences of my projects. I started noting it down and framed my own checklists and reviewed. After my maiden review, whenever I code, I started following my own checklists. That’s when I realized, how could these checklists make a huge impact on the quality of the code. Believe me or not, each time when you do a code review, it enlightens us in one way or another !

When do you think your code is good to go ?

Well, it depends on who reviews it. When you go to a peer, he/she will have her own criteria. When it comes to another person the criteria will vary, where one focuses on formatting while the other doesn’t. This will lead to inconsistent feedback. Instead, we must have a common checklist/criteria in your organization which are open to developers and reviewers. In Squashapps, we have a set of 10-15 criterias and developers check those before submitting for the review. This would be good approach to be followed as it saves time and this also lets developer’s know what to be focussed on while coding.

Automate your work !

When you know what your organization needs as a quality check, you can automate them. We can use few plugins like ESLint, which will alert you from writing stupid codes. If a pattern of your code is already reviewed, you could create a reviewed template on your own and use it for further development like the one given in this link: https://code.visualstudio.com/docs/editor/userdefinedsnippets .

Don’t make the code review a nightmare!

It is always better to have a small code reviews. Yes, I do understand the fact that some features may have lesser codes while some may have a week or a month’s work. In the case of a week or a month’s work the code gets piled up which may lead to more review comments. This will become a nightmare for both reviewers and developers. When it comes to bigger features, it is always better to do a frequent small releases. This will make the other developers to get the updated code and also reduce the merge conflict to an extent.
There are three points of time, where a code can be reviewed:

  1. During implementation
  2. When code is ready to merge
  3. After code is merged

During implementation:

Reviewing with your team mate or any colleague while developing a feature, will make you get ideas from a different perspective. Here is were pair programming dives in. This will not only helps you to find bugs in your flow, it also increases the bus factor. Else the code will be known only by one developer in your team and this may lead to may issues. Pair programming helps us to get different solutions to the same, where we can have options to choose the best approach.

When code is ready to merge

In this stage the code is reviewed by a gatekeeper like a senior developer, who is assigned to approve/decline the code to push to production.

After code is merged

We all may think, why do we review after merging? As I said earlier, reviewing is not only finding bugs in the code, it also means to share knowledge and get feedback. In this stage of reviewing, the customers/clients checks whether the code is understandable by them.

How comments play an important role in code review ?

When it comes to reviewing of a small part in a big feature, the reviewers might not know what are all you have accomplished. To make your code speak and make it self-documented, it is good to add comments like :

// This function may fail if transportMode==Train, but there are currently no 
// documented requirements or data for Trains, so there's no way to reliably test it.
function sampleFunction (transportMode) {
// Some code
}

You could also add your thought process describing why you have chosen an approach instead of other approach. So the reviewer might know, that you have thought about the other approaches too.

Submitting for a review:

It is our prime responsibility to sync up with the reviewers in a periodic time. Once you have submitted the code, there might be further feedback or declining of code. The code has to go under some process or iterations to meet the level of standards and to push to production.
Hope you guys got something from my writing to improve the code quality.
Happy coding!
Inspired from :
https://youtu.be/jXi8h44cbQA