Back in 2012, our frontend team had a shared Visual Studio settings file and a simple JSHint config. We had configured JSHint to only throw an error when building the entire project or running a test. This was not very efficient during development as it would not cause errors or warnings in real time. It was always an afterthought to go back and fix your code… and always replace those double equals with triple equals.
Fast forward today and we have an extensive document outlining best practices, a verbose ESLint config, and great formatting using Prettier.
Let’s go over how we got there.
How should you get started?
For syntax patterns, details like quotes and semi colons, or global formatting, we need to look at tools like ESLint and Prettier.
If you don’t agree with any of the rules or configuration settings ESLint provides by default, you can always turn them off. When you first enable ESLint it might look like every line of code is underlined in red, but don’t worry, as ESLint will provide you with an answer and it will help you become a better developer.
eslintconfig.json extending airbnb’s
Formatting can be tricky because everyone has a different coding style. An obvious benefit is that you don’t need to memorize a specific style — you can develop how you like and have it formatted after. We decided to “test drive” Prettier and allow it to format code with a specific command. Many teams enable it whenever you save a file but we choose to take the on command approach first. One reasoning behind this is to keep code reviews manageable. Usually, we would save the formatting until we are ready to merge our changes and then run Prettier. We understand the value that this tool provides and are deciding to take a step by step approach.
When our team adds a new member we would require them to review general development documents as well as best practice ones. After reviewing them, a new developer could then work on their first task with a basic understanding of our coding standards.
An alternative approach is to have the new member jump off the deep end and start writing code right away. This is great if the exercise is well documented but it’s also important to have one source of truth that can be referenced. Most projects contain legacy code and if a developer uses this as a starting point it’s not very helpful.
Tools like ESLint and Prettier are important because they provide a set of rules that every developer must follow. Our team uses Git and Bitbucket for version control, and utilizes the pull request feature for code reviews. When reviewing code I don’t want to see extra white spaces, line breaks, and any other distractions, I just want to see the code you added or updated (unless Prettified). Without these rules, developers would dread reviewing their peers’ code and the team’s stress levels would rise.
A developer should be able to read your code and know exactly what is going on without the use of extensive comments.
Could you imaging trying to teach a new developer all of the coding caveats your team has followed over the last decade? This would take months and wouldn’t be fair to a new developer either. The smart way now is to let your editor do the teaching. Tools like ESLint and Prettier have made our team better developers and allow us to work faster.
If you are interesting in learning more about these tools, check out the Syntax podcast where Scott Tolinski and Wes Bos go over them in depth.