DEV Community

15 Rules For Writing Clean JavaScript

Mohammad Faisal on May 09, 2023

To read more articles like this, visit my blog So you are a React developer or Node.js developer. You can write code that works. But can you write...

Read full post

niemax • May 11 '23

Great article! From my perspective the usage of if statements on one line is very clear if the condition and the function have declarative names. I often omit the braces if I'm sure it's easy to read. :)

Domenico Tenace • May 11 '23

Nice article!
I have one more point, in my opinion, that would help to write clean code in JavaScript:

Use a maximum of two input parameters for functions.

For me, this is a good helper to write clean code and visually helps to understand the code better.
What do you think?

Mohammad Faisal • May 11 '23

Totally agree. Although I would go upto 3 parameters.

Ahsan Mangal 👨🏻‍💻 • May 10 '23

This rticle is well-organized and straightforward, presenting 15 distinct rules, each with its own "bad" and "good" examples.

Himanshu Gupta • May 10 '23

Such a good article @mohammadfaisal thank you for sharing

Mohammad Faisal • May 11 '23

Thank you!

Mat Borowiak • May 16 '23

What do you think about one-liner guards inside functions? These also stack nicely. Eg:

const myFunction = (name) => {
   if (shouldStop) return;
   if (alsoShouldStop) return;

   const changedName = changeName(name);
   return changedName;
}

Jack • May 16 '23

Very few of these rules come with any actual explanation.
Some of them do have an important purpose (consistent variable casing means a developer from any language/codebase can quickly identify classes/variables/constants, for example), but lots of these rules are purely personal preference.
I think you'd find a lot of these difficult to justify other than "that's how I do it", "it said so in a book", or "because prettier"

Mohammad Faisal • May 16 '23

Maybe. But is there any universal styleguide for javascript? I guess not.
So every style guideline will ultimately fall into the "personal pereferance" bucket

Jack • May 16 '23

There are a few "standard" rulesets for eslint, and there's prettier, but ultimately there are a lot of personal preferences - which are absolutely fine to have. However, there's a big difference between personal stylistic preferences, and practices that are intended to reduce bugs/errors.

Balazs Soltesz • May 10 '23

Or in one sentence: use eslint

Mohammad Faisal • May 10 '23

Eslint is a tool that helps to apply the knowledge with ease.

Eslint is not the knowledge.

Edmundas Ramanauskas • May 11 '23 • Edited

sorry if this sounds offensive (I'm not trying to be) but neither is your post.
you wrote 15 rules but didn't explain why they're good.
also, I would like to know you're reasoning regarding points 11 and 14.
I've never seen 11 in action unless you have 2 loops in a row and want to reuse variable.
regarding 14, I've seen people using both and never had any problem myself with either. and personally I prefer using single quotes because if you need to put html or json inside the string you don't need to escape it.
point 15 is just comparing apples to potatoes. it's just a mistake and no linter will help you here. so it shouldn't be in the list because you're just saying don't make this particular mistake and it has nothing to do with coding style or rules. unless you made a mistake yourself and actually meant variable === undefined instead in which case it warrants an explanation.

Mohammad Faisal • May 11 '23

I understand your point. These rules are taken from the book “Maintainable Javascript” written by “Nicholas C. Zakas”.

So obviously we will not agree on all the points. Because style is subjective.

Pol Jeff • May 18 '23

I disagree with rules 11 and 14