JavaScript style guides have been a hot topic lately. At Blue Mango we’ve also been talking about using one for a long time, and we even got started writing one ourselves a few years ago. I don’t know why, but it never really took off.

When recently I got a little distressed about the different coding styles across projects (and departments) and variable naming went crazy again, I decided I would not rest before we implemented a style guide, and this time I would really push through!

What is a JavaScript style guide?

A JavaScript style guide is a collection of rules on how you and your team should write your JavaScript code. A style guide consists of guidelines on topics like using single quotes or double quotes, doing indentation using tabs or spaces, and what letter case to use with constants, variables, functions etcetera.

Why is this important?

Why is having a style guide so important to me? I started writing down the reasons why I think having a style guide is a good thing (next to keeping me from being annoyed). I shared them with my team and I would like to share ‘m with you too:

1. For consistency

This is the most obvious one, but we should write and style code in a consistent manner. Not only in your department, but across all departments in your company that produce code. This way we enforce a readable style that everyone in the company (and third parties) can understand and read. I really like the idea that when someone reads code, he or she should not be able to identify who wrote it.

2. For the new kid

When a new employee starts in your team, a new style guide will give him or her a guideline on how the team writes code. This will get the newbie up and running fast.

3. To learn how to be a better coder

Style guides are not just an opinion on code style, but they also (in most cases) follow best practises. As a basic example, most style guides state that you should always use semicolons at the end of every statement. This has a very good reason, and every developer writing JavaScript should understand that reason. So style guides can be used to learn best practices and learn new kids and juniors to write proper JavaScript.

4. For simplicity & focus

When having a style guide in place, we all know how to style our code, and we don’t have to think about styling and basic stuff anymore. We should not be thinking about whether we should write our functions as an expression or as a declaration. Let’s focus on the interesting parts!

5. As a guideline for code reviews

Although code reviews are not solely about style, to me styling is important when reviewing one’s code. I truly believe that ‘x’ is not a proper variable name, but some people think it is. I’ve had a lot of these discussions on coding style during code reviews. When you have all agreed on a style guide, there is not a lot to discuss anymore. When you’ve documented that x is not a descriptive and clear name for a variable, we do not have to discuss this over and over again during code reviews.

I got it. Now what style guide should we use?

After communicating these reasons to the team, we all agreed that we really need a JavaScript style guide, and that we should stick to it as well. Writing one ourselves takes a lot of time, and also there are a lot of great guides available (like this one from jQuery). So we decided to pick one of the existing ones.

I am a big fan of the Airbnb Style Guide, because it’s well-documented and they seem to have thought everything through. Plus we can integrate the settings directly into our Webstorm (or Pycharm) environment and automate stuff using JSCS. They also updated their beloved guide to ES6, so that’s cool. But in the end, choosing a style guide is just a matter of taste. You can’t choose a wrong one, as long as you choose.

When I first suggested the Airbnb style guide to the team, the tabs vs. spaces indentation discussion started all over again. People asked whether we could do some exceptions on the given style guide. Well, of course we could. We’d just have to fork Airbnb’s repo and change it to our liking.

But I strongly recommended to stick with their guide, because I don’t want our guide to get outdated when they choose to update theirs. We had to give in one some small issues, but the team agreed!

In closing

I hope you agree that using a style guide for your JavaScript development is important. It does not matter which one you choose, as long as you pick one (or write one yourself) and stick to it. If you haven’t already done so, start today! I promise you’ll like it.

Of course discussing certain styling decisions is always educative and interesting, so you should never stop questioning your style guide.

Btw, if you are serious about styling and clean code, you should check out Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.