Code styles, and why they matter

Code linting and code styles are not uncommon, they are used in the majority of NPM packages and open source projects from my own personal experience, yet I still see a lot of developers, juniors and mid-weights, who never used linting or even have a code style they stick to.

Don't get me wrong, you don't need linting or a code style for write good code, but it can serve as a very helpful guide to keep your code readable, uniform and even in some instances help you find bugs before you even test your code.

So let's talk about what linting is, and the benefits from using a linter and having a code style.

The benefit of a code styles

In short, codes styles helps you keep your code consistent. Reading other peoples code, which keeps a consistent style throughout, makes it much easier and quicker to get your head around what they have done and how.

Imagine reading an assembly manual for a piece of IKEA furniture, their illustrations and the flow of their manuals are very consistent which helps you understand each step. Now imagine each step had its own type of illustration, and some steps might even have no pictures and just text explaining what to do. This would result in you never being able to get used to the flow of the instructions, and you would have to think long and hard about what it wanted you to do at each step.

This is why a consistency with how you structure your code is important. It helps others (and yourself) more easily read and understand the instructions, which is your code.

Which style should I choose?

Honestly, it doesn't really matter which style you go with in my opinion, so long you stick with it throughout the whole project. If you change your code style mid-way through a project or in some files, it sort of negates the whole point of consistency.

If you are looking for some more established code styles, here is a couple to look at (in no particular order):

Airbnb (JavaScript)
Standard (JavaScript)
Idiomatic (JavaScript)
Google (C++, Objective-C, Java, Python, R, Shell, HTML/CSS, JavaScript, AngularJS, Common Lisp, and Vimscript)

I personally recommend choosing one of the more popular code styles as they are more widely used, but in the end you should choose whichever one you like the most and stick with it.

Remember, consistency is key.

Applying your code style

When it comes to actually apply you code style, it can be really hard to make sure you actually apply fully throughout your codebase, especially in the beginning, as you would essentially need to memorise the code style before you can even use it.

This is obviously not ideal, specially if you move between multiple projects (eg contribute to open source projects with a code style set by the maintainer(s), and your own projects).

Heads up! Since I work mostly with JavaScript today, it will be what I use in context for the next part of this post.

Luckily, there is an automatic linting tool which will highlight inconsistencies and places where you haven't applied your code style. This means, you can pick a style you like fairly quick and start to apply it properly, immediately.

The tool I am referring to is ESLint.

I am not going to go into how you install it, since it can vary from each OS and editor combo. Most popular editors (Sublime, VSCode, Atom just to mention a few) have this preinstalled or should be easily added via plugins.

Setting up ESLint rules

With ESLint installed, you will need to define which style you want to use. You can do this by creating an .eslintrc file at the project root.

The .eslinterc file is basically a JSON file, and with that in mind we can setup our rules:

{
    "extends": [
        "google"
    ],
    "rules": {}
}

In this example, we load in Google's code style, and if we wanted to make personal changes to the style, we can add any additional/overwrite rules inside the "rules" object. For example, if we wanted to update the "max-len" rule so it ignores strings, urls and template literals, we can add the following overwrite:

{
    "extends": [
        "google"
    ],
    "rules": {
        "max-len": [
            "error", {
                ignoreTemplateLiterals: true,
                ignoreStrings: true,
                ignoreUrls: true
            }
        ]
    }
}

One of the big benefits from having an ESLint config file, is not just that your editor will tell you where you are making mistakes, but it will also tell others who you want your code to be written. So if anyone where to contribute to your code, they will have the same code style rules as you.

Conclusion

Choosing a code style and sticking with it (at least on a per-project basis) will be a massive boon to making your code more readable, but it also helps you find bugs you possibly would have otherwise missed.

Also, it is important to know that it is absolutely OK to spread your code out a bit, using more line-breaks for readability etc. The compiler does not care about your white space or code style, so don't worry about it; instead worry about making your code better for humans.