Use === Instead of ==
JavaScript utilizes two different kinds of equality operators: === | !== and == | != It is considered best practic...
For further actions, you may consider blocking this person and/or reporting abuse
The article could do with the code being in Markdown code escapes:
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()
?Sure
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.
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,
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.
Agreed!
Thanks for the suggestion. I'll include that too..
Have a good day😋
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
.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.
A useful reference. Thank you for sharing.
If you want to add something please go ahead.
You can write anything in comments and i will add it to the post!! Cheers😋
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?
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.
Totally agree:
Or
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.
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...