DEV Community

JavaScript Best Practices for Beginners

Raghav Khanna on June 02, 2020

Use === Instead of == JavaScript utilizes two different kinds of equality operators: === | !== and == | != It is considered best practic...

Read full post

Mike Talbot ⭐ • Jun 2 '20

The article could do with the code being in Markdown code escapes:



   ```js
   
   code goes here

   ```

I hate semicolons - unless you are using something like Prettier - most people add too many. A fanatical debate of course, but I don't use them.
Perhaps an example of building a string using Array.join()?

Raghav Khanna • Jun 2 '20

Sure

József Sallai • Jun 2 '20

I agree with most of these, except the semicolon one. It's perfectly fine if you don't use them.

I think what this article is missing is a section about consistency. Double quotes vs single quotes? Semicolons or not? It doesn't matter as long as you're consistent with it. Also, you could perhaps suggest using ESLint.

James Thomson • Jun 3 '20

I'd argue that beginners should use semicolons to understand the implications of writing without them.

For the most part you shouldn't have any issues, but there are some gotchas that will trip up beginners.

For example,

const test = () => {
 return 
 {
  ok : true
 }
}
console.log(test())

In the eyes of a beginner, what do they expect this code to do? If they're not used to writing with semicolons they might expect it to return the object, but instead they get undefined.

I do 100% agree about consistency. Whichever way you go, be consistent.

Mike Talbot ⭐ • Jun 2 '20

Agreed!

Raghav Khanna • Jun 2 '20

Thanks for the suggestion. I'll include that too..
Have a good day😋

Xavier Brinon • Jun 3 '20

That's what standardjs.com/ and prettier.io/ are for I guess.

I tend to format code the way I like before starting reading it, so the original styling is gone anyway.

Devs should focus more on making the code readable to other humans first; spend some time finding the most relevant names. Show the intent and make the context of the code obvious. The comments should be about the why not the how. Always name your functions. Be as declarative as possible, don't try to go for the creative solution if that makes it unreadable (I assume everybody should know how to read an Array.reduce... 👍🏻 ).

Technically you should use === when you are not sure about the types of what you are comparing. If you know them, == is perfectly fine. Based on the specs === switches to == when the 2 values are of the same types. I linter forces the === anyway 🤷🏻‍♂️

I don't see why an IFFE is best practice btw.

A best practice I like to add is to follow the new features appearing every year as they tend to make the code more declarative. I get sad everytime I see a index === -1.

Etienne Burdet • Jun 2 '20 • Edited

You can write excellent spec compliant code and omit semi-colons. See :

It's a preference, not a bad/good practice. The debate is endless, nobody ever won it. It's down to preferences.

Richard Shepherd • Jun 2 '20

A useful reference. Thank you for sharing.

Raghav Khanna • Jun 2 '20

If you want to add something please go ahead.
You can write anything in comments and i will add it to the post!! Cheers😋

Kevin Alemán • Jun 3 '20

As you'll notice, the indentation mimics the functionality of the curly brace.
First, what indentation? I see every line at the same indentation level. And second, what do you mean?

Keff • Jun 3 '20

It might seem unnecessary at first, but trust me, you WANT to comment your code as best as possible. What happens when you return to the project months later, only to find that you can't easily remember what your line of thinking was. Or, what if one of your colleagues needs to revise your code? Always, always comment on important sections of your code.

I understand your point, but I tend to not agree with this because code should explain itself, otherwise, we would use Machine code directly, for me, Programming languages (at least high-level ones) tend to be quite readable already if you code in such a way that is understandable. If not, you might want to look into clean code examples and principles, they can make a huge difference.

"Good code should explain itself with the need for few comments"

Another bad thing about comments IMHO is that you're creating a new "dependency" that you need to update whenever you edit that code, if you forget to update the comment after updating the code it will result in conflicting explanations, on one side the comment says the code does one thing but the code tells you it does another thing.

As you pointed out, I prefer using comments to explaining the line of thought of complex functionality, were just the code must not explain it correctly, or it uses an abstraction of some kind, which cannot be interpreted just by looking at the code.

I think comments can be useful, but it is not a sign of good code IMO.

Mike Talbot ⭐ • Jun 3 '20

Totally agree:

     function process(b) {
       //Get the angle
       let a = b.rotation
       //Rotate
       a += Math.PI
       //Return the rotated angle
       return a
   }

     function getReverseAngle(gameObject) {
          return Math.PI + gameObject.rotation;
     }

Willem Odendaal • Jun 3 '20

Do people really use the web nowadays with javascript disabled? Maybe I've just been web-devving so long that I don't think of that as an option anymore.

Keff • Jun 3 '20

Doubt it, although some institutions or old school people might still use it. I know people that have it disabled on mail clients, as well as automatic image rendering...