One of JavaScript’s superpowers is that it’s a really flexible language. It can be written in many different programming styles, and all of them are equally valid JavaScript (though maybe not equally useful approaches, but that’s a whole different topic). Give a coding task to 10 people from different technical backgrounds and you’ll likely get 10 very different source files that all do the same work. Same inputs, same outputs, totally different code.
The flip side of this flexibility is that there is a wide variety of opinions on what proper formatting looks like, as well as best practices around a wide array (pun intended?) of different coding patterns. When you’re coding on your own it’s not a big deal, but when you’re coding on a team or open source project, it can quickly become an issue. To avoid confusion, bugs, and extra cognitive load of understanding different conventions, all code within a given project should adhere to the same style, as if it were all written by one person.
Programmers can be pretty pedantic sometimes, and there have been countless 🔥 heated 🔥 arguments over placement of brackets, tabs vs. spaces, variable declaration, an so on. These arguments are unnecessary, divisive, and time-wasting. Please, don’t engage the nonsense. Nothing in these conventions, one way or the other, is going to make or break your project. For any group code (which is most code), there should be a standard set of styles and best practices established by the team, and automatically enforced by tooling.
Two great tools that work hand-in-hand for this are prettier, and ESLint. Prettier is just a style formatter, and an opinionated one at that. There are few configuration options because we really don’t need to argue about style. The creators of prettier have chosen a reasonable set of default styles so we can all move along to important work, like thinking about the logic and structure of your program. Their stance is, “By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles.” Prettier won’t change the logic of your code at all, so before and after prettier runs your code is functionally identical. Prettier is most frequently run on file save in your code editor via a plugin. That means you can type your code however you’d like, and when you hit save your editor will first run it through prettier to reformat it, then do the actual save.
ESLint, on the other hand, is a linter rather than purely a style formatter (though it can and does to style formatting too). A linter aims to enforce not only code style, but also code quality rules. These are conventions that, when followed, lead to cleaner code and fewer errors. There is a long list of configurable rules with a sensible set of defaults that you can use from the start. ESLint will warn you if you are violating any of the rules, and can also fix many of the issues for you if you’d like. ESList commonly runs in your code editor in realtime via a plugin, letting you know of any issues or errors as you go so you can fix them immediately, very much like a spellchecker. You can also run it via a git pre-commit hook so you are forced to fix your code before pushing it up to git (and saving yourself the hassle of having to fix and re-push if your peers or the build process catches the error later).
Since there is a good bit of overlap between ESLint and prettier, you can actually run prettier as a plugin within ESLint, and also use a config for ESLint that will disable all conflicting style rules. Configs can get pretty involved, so start off with defaults and tweak from there as necessary, when the need arises.
With all the things to remember when coding in JavaScript, style rules really shouldn’t be taking up any brain space, nor causing any arguments between teammates. Using these two automated tools will greatly improve your code style and quality, all with only a bit of effort of initial setup. Good luck and happy coding!