Perhaps this will come across as a “how did you even work before” sort of post and bring shame upon my family, but I’ve just come to use and appreciate the magic of linters and wanted to share my experience.

Old habits die hard, but there are ways to fix that. Somehow, in all my time as a front-end developer I’ve always ended up as the sole coder/maintainer of my projects’ stylesheets. I’ve had times where a mentor may have reviewed my code and offered advice, but besides a case like that I was usually just let loose upon the styles as the sole “master”. Now, I’d like to think that my code is fairly clean, and I’ve tried to pickup good patterns along the way.

This isn't so bad, is it?

This isn't so bad, is it?

However, the time comes to reach a higher level of organization when new developers enter the fray that is “shared code”. With ongoing UI work reaching increased levels of collaboration, a standard must be set so that all developers are coding as similar as possible. This will make sure that this fresh new codebase doesn’t suffer the fate of some legacy code which becomes an unmaintainable or confusing mess. This makes life easier for any current developers working on the same files as well as any future developers who will quickly understand there’s a pattern throughout all the code.

In our case, we are using sass-lint for our styles and eslint for the Javascript. In both instances, each of these linters will look for a little configuration file sitting in your project folder to get the “rules” you want to follow. For example, in my code above you might notice I list my CSS properties in the (superior) alphabetical fashion. However, in our project we have begun to use the SMACSS ordering which is based off some different principles, and so that’s what the linter will want to enforce. Almost any IDE will have a plugin of sorts to integrate the linter straight in and lint your code live. So with my Atom ready to go, a quick package install was all I needed to get:

Yay, errors!

Yay, errors!

Note the handful of errors and warnings in my editor now. As I code, the linter will catch any errors right away, highlight them, and let me know what it is I need to fix. In the above case, I ran the linter through a large amount of already-written code and so I had to begin cleaning up. However, moving forward I can now adhere to a nicer standard than my own custom little method of SASS structuring.