In my personal projects I've started using the == operator almost exclusively, instead reserving === for instances when type coercion isn't feasible. One important thing I want to preface in this post is making sure you're following the conventions and standardizations of your team. If === is more used commonly in the codebase, you should keep the pattern. In your own code or project though, it's a different story, as you can experiment with your own style.
In the Javascript community, there is a long-standing debate on the use of the double equals = operator versus the triple equals === operator. Developers often hesitate to use == due to type coercion, others find it a practical tool.
Coercion Isn't Always A Bad Thing
The main difference between == and === lies in type coercion. The === operator, also known as the strict equality operator, does not perform type coercion. It returns true only if both the operands are of the same type and contain the same value. On the other hand, the == operator, also known as the loose equality operator, converts operands to a common type before comparison.
Type coercion can be a powerful tool when used correctly. It allows developers to compare values of different types without explicitly converting them, making code more readable and less verbose. For example, "5" == 5 would return true. In this case, == operator can be more forgiving, allowing for smooth and seamless data type transitions. To achieve this you would have to parseInt() before comparing. Why take an extra step?
Knowing When to Use == Safely
It's crucial to understand the scenarios where the == operator works safely without causing confusion or introducing bugs. The == operator works perfectly well when comparing values where type coercion is not a problem or is even desired. It shines when comparing numbers to strings, nulls to undefined, and objects to strings.
Safe Practices With == Operator
It's crucial to keep in mind that every tool and operator in JavaScript has its purpose and place. The == operator is not inherently unsafe; it's the lack of understanding about how and when to use it that can lead to unexpected results.
To safely use the == operator, you must:
- Understand JavaScript's type coercion rules.
- Use
==when you want to compare values, and the type conversion could simplify your code. - Avoid
==when comparing with booleans or empty strings. - In conclusion, it's essential to recognize that the
==operator is not a hazard waiting to trap unwary developers. Instead, it's a feature JavaScript that, when understood and used correctly, can contribute to cleaner and more efficient code. The key is understanding JavaScript's type conversion rules and knowing when to use which operator.
Understanding the tools at your disposal and using them correctly can significantly improve your programming efficiency and proficiency.
Top comments (4)
It sounds like you're suggesting only using it for comparing strings to numbers, but even if you restrict it to that it's idiosyncratic to say the least. Without looking it up, do you know which of these are true?
IMO a blanket ban (linter rule etc) is easier than trying to keep all the rules in your mind and spot all the potential footguns any given time you use it. The one exception is
x == null, which is a useful shorthand forx === null || typeof x === "undefined", and it's easy enough to remember the rule for that one as null and undefined are only ever loose-equal to each other.Fully agree. Type coercion in JS is super useful. Understanding is key.
There has been an unfortunate tendency over the years to advise more junior devs to 'stay away' from certain parts of JS as they will give 'unexpected' results. To my mind, this is absolutely terrible advice. The results are only 'unexpected' if your understanding of the language is not up to par. Teaching upcoming devs in this manner is nothing but a recipe to steadily lower the ability of successive 'generations' of developers. Each mis/under-informed group will eventually become senior and pass on their misguided learnings to new inductees who blindly accept it.
The implementation we have is deeply flawed. Telling future devs "hey, this footgun exists. You can use it to shoot yourself in the foot. Don't use the footgun that will shoot you in the foot." is pretty solid advice.
There's 0 reason to have a deep understanding of deeply flawed functionality when it's easily avoidable, especially when not using it improves the quality of your code and makes it easier to reason about.
There are vanishingly few reasons to coercively compare values that can't be solved by being explicit rather than terse.
In a theoretically sane language type coercion is theoretically powerful.
As lionel-rowe lays out in his comment, JS isn't really a sane language when it comes to equality between types. Using
==is an invitation to break the first rule of not getting got.(Don't get got)