Insights on code reviews

“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: .

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 :

Validations in Full Stack Development

Full Stack Development, a quite tough to explain in a couple of lines. It takes ownership of the entire application from top to bottom. If you see a person as Full Stack Developer, he must be an all-rounder to develop an application from zero to high excellence. Full Stack Development includes 2 layers of architecture :

  1. Front-End Development (aka Client-Side / Presentation Layer)
  2. Back-End Development (aka Server-Side / Business Logic Layer)

Each Layer should have a data validations. Let’s dive in deeper,

Client-Side Validations

Validation takes place on the client side(web browser). It would be more frustrating to wait for the server response and re-enter the form that has nearly 100 inputs. So it is mainly for formatting data instantly and for the quick error recovery process.
Client-side validation gives the user feedback ASAP without having to wait for the server. It is an added topping, but not necessary. This will avoid the majority of validation issues and unnecessary processing from the server to perform data validations.


  • Faster than Server-Side Validation
  • Better user experience can be provided by responding quickly(like invalid phone number, required fields,etc..)
  • Saves network bandwidth, traffic API calls


  • Not Secure and useless if client-side scripts are disabled(javascript disabled)

Server-Side Validations

It is all about the data validation takes place on the server-side using the server-side scripting language. If you use server-side validation, you are developing a more secure application. Because client-side validations can be bypassed easily.

Let’s take a scenario. If a user is a technical guy/ a malicious user, he can pass invalid inputs through API testing tool or he can disable the javascript in client script or some malicious attack to skip client side validations. In these cases, validation will not happen. This may lead to incorrect entries, server downtime if any serious errors, etc, So we should verify on the server as well.

There are few libraries(eg., express-validator, etc) available to validate the inputs. Better, write a few code snippets for validations before continuing your business logic like‘/api’, async(req, res) => {

 let isValidationPassed= await validateAndHandleInputs(req);


  //continue the business logics




  • More Secure than Client-Side Validation
  • Validation Techniques and Logics cannot be viewed/modified by the user.


  • Comparatively slower execution