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 :

A dive into “Vuex” !

Let’s meet our hero – “The Vuex”!

Vuex is a state management library that is used commonly in vue.js. But why do we use it? Vuex is very much useful in passing the data from one component to another component.

We can pass data from the parent component to child component using props, but when the child component has many nested siblings, the data passing between the child components becomes difficult and that’s where “Vuex” comes into play !!

Store :

A store is a global object that keeps track of all the state changes of the app across the components.

But what makes it different from other objects?

  • Vuex stores are reactive – every state changes are updated efficiently in the store
  • Vuex stores are read-only – It is not possible to change the state properties directly in the store. The only way to change a store’s state is by explicitly committing mutations.

We can create a store by creating an instance of vuex like :

const store = new Vuex.Store({ state: {} })

In order to integrate vuex with vue, we have to add the store in the vue instance by :

const App = new Vue({ store })

In order to keep track of the state changes, we have to access the state in the “computed” property in vue component

Now we have created a store, but how do we access the store data?

We access the store by the following methods :

  • Mutations
  • Getters
  • Actions

Mutations :

These are functions used to update the state. They behave like events and we have to use “commit” in order to invoke them.

To be clear, we define the mutation by :

const store = new Vuex.Store({

mutations: {

  yourMutationFunction (state, payload) => {




We invoke the above mutation by:

this.$store.commit(MUTATION_NAME, {payloadData});

Getters :

Applicable to a scenario where we have to get a value from the store that is obtained by manipulating the state data, then we use “Getters”. Having these manipulations in the store makes the “Getters” reusable in other components as well.

Getter functions are created by :

const store = new Vuex.Store({getters: { yourGetterFunction : (state) => ( ) } });

And we invoke the getters by,


We also have a helper method called “mapGetters” to invoke a getter function in the component.

Example :

import { mapGetters } from ‘vuex’

export default {
 // some code ..
 computed: {
   …mapGetters([   // we use spread operator to append the mapGetters to the computed object

But when we have no manipulation in the state, we have to use mapState helper to fetch the data in the store directly from the store.

computed: {



Actions :

They are generally functions, that is invoked to perform some backend calls or any other asynchronous operations before mutations. Actions keep track of the mutation changes correctly in case of asynchronous operations.

actions: {
 yourActionMethod({ commit }) {

Actions are invoked by dispatching them using store object or mapActions helper function

Example :


Or in components by :

methods: {


Thus, the flow for the state from component to store will be like :

Sources :