DEV Community

Hudson Burgess
Hudson Burgess

Posted on

Good first steps for a JS style guide?

Right now I'm essentially the only frontend dev at my company, but we have plans to bring on one more (sometime soon, I think? ¯\(ツ)/¯). With that in mind, I'd like to start writing some sort of JS style guide / best practices doc. What are some good first items to include?

Oldest comments (13)

Collapse
 
nektro profile image
Meghan (she/her)

Have you seen ESLint? Here’s the styles I use:
eslint.org
github.com/Nektro/modules.js/blob/...

Collapse
 
dobesv profile image
Dobes Vandermeer

Use prettier and eslint on default settings. Or use Airbnb style guide. No need to reinvent the wheel.

Collapse
 
kayis profile image
K

I don't know much about this matter, the only thing I read recently was this:

Collapse
 
dobesv profile image
Dobes Vandermeer

Neat, thanks for the tip.

Collapse
 
hudsonburgess7 profile image
Hudson Burgess

Skimmed the Airbnb style guide; good stuff but it looks like a huge overkill for what we need right now. Looking into eslint / tslint right now.

Collapse
 
letsbsocial1 profile image
Maria Campbell

eslint rocks. I swear by it.

Collapse
 
dobesv profile image
Dobes Vandermeer

Most of airbnb style guide is enforced by eslint if you setup their eslint preset and use prettier.

Collapse
 
lexlohr profile image
Alex Lohr

Concentrate on the open questions. Accept different opinions and find a compromise. The bigger the team, the less risk your coding style should have (for example, leaving out semicolons).

Collapse
 
blouzada profile image
Bruno Louzada

In our company StandardJS worked really well, no one needed to stop and think a good good codestyle we just used standardjs

Collapse
 
xowap profile image
Rémy 🤖

I go with AirBnB style with a few variants. The main one is a 4-spaces indentation to stay consistent with Python. Other stuff include deactivating options that are way too restrictives (like the ability to await in a loop, which is to me one of the main selling points of async/await).

Collapse
 
letsbsocial1 profile image
Maria Campbell

Also make sure to develop great workflow automations. i.e., for pure js applications, react applications, etc. Saves so much time. Currently I have one I developed (over time) for pure JS (FE) and one for React (without CRA, but emulating it). Now working on automating workflows for backend as well. Developing good workflows takes time and lots of fine tuning. Especially since things change so rapidly, as in open source for example!

Collapse
 
superkarolis profile image
Karolis Ramanauskas

Good you give an example of a good workflow? Especially would be interested in JS/React ones.

Collapse
 
mbtts profile image
mbtts

This is a good question and interesting topic, my bias is towards the thinking that it doesn't really matter what you styles you decide upon as long as they are enforced and consistently applied.

As such it is probably better have no style preference until there is time to configure it for your editor(s), build and CI pipelines. It is a huge waste of time if it is something you spend a lot of time manually overseeing and discussing in code reviews etc.

As such I fully agree with the other suggestions to look into tools built for ESLint or StandardJS. Prettier is a formatter only and not a linter, so can be combined with either ESLint or StandardJS.

I also wouldn't worry about these being heavy weight as the point of the editor integration (and build integration) is that you don't need to learn each and every rule by rote - rather that the rules are be checked on your behalf as you type (or save).

The idea with Airbnb (and other guides) is that you take it as a base and then customise it to your needs by overriding rules you disagree with or do not require. In practice this involves applying it to your project to see how many errors and warnings you get (it might be a lot and don't worry if this is the case as a lot will be duplicates). Then spend the time tweaking the rules to your liking. For a code base which is not linted this will take a bit of effort upfront, but the benefits far outstrip this initial investment.

Later on you may wish to look at a quality gate tool like SonarJS. This is concerned with enforcing consistent style, but also performs static analysis and catches possible bugs, code smells and even some security issues.