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?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (13)
Use prettier and eslint on default settings. Or use Airbnb style guide. No need to reinvent the wheel.
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.
Most of airbnb style guide is enforced by eslint if you setup their eslint preset and use prettier.
eslint rocks. I swear by it.
I don't know much about this matter, the only thing I read recently was this:
Neat, thanks for the tip.
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
awaitin a loop, which is to me one of the main selling points ofasync/await).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!
Good you give an example of a good workflow? Especially would be interested in JS/React ones.
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.
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).
Have you seen ESLint? Hereβs the styles I use:
eslint.org
github.com/Nektro/modules.js/blob/...
In our company StandardJS worked really well, no one needed to stop and think a good good codestyle we just used standardjs