JavaScript Style Guide.

If you’re like me, you earn your bread by writing JavaScript; Sometimes really good JavaScript and sometimes, JavaScript full of codesmell. Folks, it’s about time we make use of something called as a style guide for our JavaScript (and React if you’re into React/Vue or other big guns).

But first things first.

WHY THE HELL DO WE EVEN NEED THIS?

Well, for the following reasons.

• Your code will look amazing and will be readable by you even years down the line.

• Your code will have very less non idiomatic parts. It’ll automatically be somewhat good practice if you follow this style guide. For example, it will highlight an error in your IDE or your favorite text editor if you declared a useless function or a redundant variable.

So by implementing a style guide, your IDE or editor will automatically tell you when you’re writing bad JS and not just syntactically wrong JS even before you run a single line of code.

• Two people won’t be auto-aligning the same file with different formatting so as to form an unending cycle and countless git merge conflict cycles. (Trust me, that’s something that has happened to me at my office)

Ummm alright – But what’s a style guide? It’s a guide that recommends you on how to format and structure your code. Lint basically means to hint beforehand a bad practice or an error in your code. A style guide in JS can be implemented using eslint. Eslint is by far the most popular tool for code hinting in JS. (There’s JSHint too but it isn’t as popular)

In eslint, there is a .eslintrc file we should use. It’s basically a json file with a fancy name and it lives inside the root folder of our project. (alongside .babelrc and package.json)

Touch this file and install the following dev packages to set up eslint in your next JS project.

Sidenote – There’s an alternate way to configure eslint without the .eslintrc file. You can place a key called eslintConfig inside your package.json with a value same as that of the json that’s inside your .eslintrc. This will however make your package.json file fat and it comes down to personal preference whichever technique you want to use. If my override rules are short, I prefer the package.json way where as if it’s long, I’m quite fine with the addition of the .eslintrc file.

Now, after this comes the important part.
Making our IDEs or text editors use this style guide and hint changes in our code on the fly inside its own UI.
There’re plenty of really good articles on this and I think I can point you to a few. (Skip the parts where they add the eslint itself to the project. We’ve already done that, remember?)

Upon following this article, you and your the whole team (if they weren’t grumpy enough to try this at the first place) will commit and write code that is beautifully formatted and according to the same style rules. Moreover, you can configure your IDE or text editor to automatically fix and format your files using the same style guide on every save! Neat huh?

eslint in action.eslint helping us churn out great looking and idiomatic JSX.

And profit!

A full documentation of a very good style guide written by Airbnb with what’s good and what’s bad in JS can be found here. I use the same guide but with minor changes that I listed above in my .eslintrc file.https://github.com/airbnb/javascript

Just one or two commands with one extra file. That’s all it takes for you to feel proud of your code.