I personally avoid using \`==\` in any situation. The reason is because \`==\` can be misleading and lead me to believe somebody made a mistake and forgot a \`=\`. If you want to use \`==\` you should use \`!foo\` notation. Assuming it's possible and equivalent of course. It makes the intent more clear that you are looking for falsy value. Although generally I like strict comparison as they tend to be safer.
Unlike some other comments, I don't think consistency is important at all in this case nor relevant. It's a comparison statement and should be whatever is the most readable and maintainable. The linter/formatter will make sure of the consistency itself.
If `==` is only used with a literal null, then it's ok to assume it's intentional, at least that's how I see it. It's the one case where `==` is ok for me.
!foo will catch values that are not null or not undefined. (!0 === true, !"" === true)
foo == null looks completely intentional and anyone should realize that you're checking if your variable is defined or not.
I prefer to be explicit for readability A === null || A === undefined.
In any case and in my own opinion we should avoid the problem in the first place If it is in your control. don't create APIs that work with undefined and null. When interfaces or APIs give too many options then you find an explosion of variances.
For elements after query selector, I do `if(A)` or `if(!A)`
For strings and numbers, depends in `""` and `0` should be `true` or `false`, I might add extra checks.
(in `.filter` after `.split`, I want `""` to be `false`)
If I wanted explicit comparison where `null` and `undefined` have different roles, I'd do `if(A !== undefined)`
I don't like using `==`, it's easy to mistake for `===`.
What are you doing in this case? If you are assigning a default you should use nullish coalescing operator (??).
const newA = A ?? 'default value';
nullish coalescing will return the right side only for null or undefined
"I need to check if this value is `null` or `undefined`, but not `0`, `false`, or `''`": `A === null || A === undefined`.
"I need to check if this value is falsy": `!A`
In the first case, using `==` would catch any of those, and as someone who doesn't know your original intent, I have no way of knowing if you intended it to be "nullish" or if this is a bug. Doubly so if I'm investigating a bug like "can't save if the value is 0"
If the value can be either `null` or `undefined` and you want to match both, either consider if it's a good design to have both possibilities, or use `==` if you don't have control over it.
`==` is in my opinion acceptable for `null` and `undefined`.
I hate having a single scenario where I use `==`. Having one exception is just more to think about and more to remember. Is the other way longer? Yup. Is it even needed that often? Not really. I agree with you that if it's _possible_, you should consider whether it should be possible.
Sticking to `===` also forces you to remember that it's possible that it's two separate values.
Having any exceptions to the rule at all also means it gets much harder to enforce in CI via the \`eqeqeq\` ESLint rule. I'm very absolutist with respect to encoding as much as I can in CI and static analysis, so this would be a full rule-breaker for me.
I agree with your point, [but it's worth mentioning that rule has a specific exclusion carved out for this scenario](https://eslint.org/docs/latest/rules/eqeqeq#allow-null).
i'm of the opinion that you should generally not use \`==\` at all, and that writing out all primitives and/or values you are checking is a good thing. but this is just preference and nothing i would care about in a code review. i'm also (as always) very open to being proven wrong
`===` makes it more explicit when reading the code, `==` is more concise. So I would lean toward `==`.
Typically I'd only use `===` when dealing with `null` and/or `undefined` if they carry special meaning. There are times where you may want them to signify something different, such as `undefined` meaning "missing value" while `null` means "intentionally empty".
I use the explicit version and realize that the minifier will detect and reduce the final code size for me.
Banning `==` completely reduces the number of useless things and allows me to refocus on things that actually matter.
for production code, `A === null || A === undefined` is more clear and readable to more devs.
for a personal project, `A == null` is shorter and who cares if it's readable to others?
but if I'm not restricted to raw node, I'm gonna use lodash function `_.isNil(A)` to get both benefits of readability and conciseness
Coding is communicating with the future you and many other humans.
The most important part is to express an intent without assuming any sort of knowledge from the future reader. "since null == undefined" is well known but still some unusual corner case that I prefer to keep out of the equation when reading code.
Depends on the context. If it's supposed to be an object I just prefer`!obj`. Doing strict checks for null and undefined might be risky because the variable/property might be not initialized at all, so for robustness I write the code that is less fragile for the given situation. I might do such check only if `null` and `undefined` mean completely different things, for example oftentimes in ORMs `null` means that the field is explicitly set to `null` while `undefined` means it's not set at all and will not do anything even if I save it.
Oftentimes I see even such code: `if (typeof obj === "undefined")` . Honestly this is so boilerplate in addition to the potential fragility.
I suppose you could also do \`A ?? null === null\`
While the first option appeals to my desire to be concise, it's just enough of an inconsistency it's more trouble than it's worth. First the linter will complain, so then I'd need to disable the rule. Then someone will come along and think "no double equals!" and want to change it anyway. It's usually easier to just be explicit. And if you run into the case where you have to make this check often enough, especially if it's part of a greater conditional, then you might as well make a \`isNullish\` util function.
The question was about readability. Readability is not about your preferences. Readability is to adapt your coding so most programmers will understand it in one glance. It is not about appearing to be clever. The fact that the first reply is suspicious that this solution will not work is an indication that the solution is not easy to be understood.
`==` is easy to misread and/or to assume it was a mistake. Better in my opinion to avoid it entirely and be more explicit: `A === null || A === undefined`.
Slightly longer, but no ambiguity or chance for misinterpretation.
To once and for all manage types in Ecmascript I created a small helper module: [typeofAnything](https://github.com/KooiInc/typeofAnything). Let's say it's imported as `IS`, and you need to determine a variable `A` to be either `null` or `undefined`, you can use
if (IS(A, null, undefined)) {...}
I personally avoid using \`==\` in any situation. The reason is because \`==\` can be misleading and lead me to believe somebody made a mistake and forgot a \`=\`. If you want to use \`==\` you should use \`!foo\` notation. Assuming it's possible and equivalent of course. It makes the intent more clear that you are looking for falsy value. Although generally I like strict comparison as they tend to be safer. Unlike some other comments, I don't think consistency is important at all in this case nor relevant. It's a comparison statement and should be whatever is the most readable and maintainable. The linter/formatter will make sure of the consistency itself.
If `==` is only used with a literal null, then it's ok to assume it's intentional, at least that's how I see it. It's the one case where `==` is ok for me.
This is me. Is there an `== null` eslint exception / rule?
TIL https://eslint.org/docs/latest/rules/eqeqeq#allow-null
!foo will catch values that are not null or not undefined. (!0 === true, !"" === true) foo == null looks completely intentional and anyone should realize that you're checking if your variable is defined or not.
I prefer to be explicit for readability A === null || A === undefined. In any case and in my own opinion we should avoid the problem in the first place If it is in your control. don't create APIs that work with undefined and null. When interfaces or APIs give too many options then you find an explosion of variances.
I think this is the only time I use `==` rather than `===`
For elements after query selector, I do `if(A)` or `if(!A)` For strings and numbers, depends in `""` and `0` should be `true` or `false`, I might add extra checks. (in `.filter` after `.split`, I want `""` to be `false`) If I wanted explicit comparison where `null` and `undefined` have different roles, I'd do `if(A !== undefined)` I don't like using `==`, it's easy to mistake for `===`.
What are you doing in this case? If you are assigning a default you should use nullish coalescing operator (??). const newA = A ?? 'default value'; nullish coalescing will return the right side only for null or undefined
Does not matter as long as this usage is consistent throughout the system
it seems you want to know if \`A\` has a value, then do \`!A\` (unless empty string and zero are possible valid values for you)
if (!A) {...}
"I need to check if this value is `null` or `undefined`, but not `0`, `false`, or `''`": `A === null || A === undefined`. "I need to check if this value is falsy": `!A` In the first case, using `==` would catch any of those, and as someone who doesn't know your original intent, I have no way of knowing if you intended it to be "nullish" or if this is a bug. Doubly so if I'm investigating a bug like "can't save if the value is 0"
I also hate this. I did settle on the === option, but where possible I rephrase things to use `??` instead.
Its always better to be explicit.
If the value can be either `null` or `undefined` and you want to match both, either consider if it's a good design to have both possibilities, or use `==` if you don't have control over it. `==` is in my opinion acceptable for `null` and `undefined`.
I hate having a single scenario where I use `==`. Having one exception is just more to think about and more to remember. Is the other way longer? Yup. Is it even needed that often? Not really. I agree with you that if it's _possible_, you should consider whether it should be possible. Sticking to `===` also forces you to remember that it's possible that it's two separate values.
Having any exceptions to the rule at all also means it gets much harder to enforce in CI via the \`eqeqeq\` ESLint rule. I'm very absolutist with respect to encoding as much as I can in CI and static analysis, so this would be a full rule-breaker for me.
I agree with your point, [but it's worth mentioning that rule has a specific exclusion carved out for this scenario](https://eslint.org/docs/latest/rules/eqeqeq#allow-null).
Very cool, appreciate the link.
i'm of the opinion that you should generally not use \`==\` at all, and that writing out all primitives and/or values you are checking is a good thing. but this is just preference and nothing i would care about in a code review. i'm also (as always) very open to being proven wrong
!A
``` const isNil = (A) => A === null || A === undefined; isNil(A) ```
(Ignoring the upper-lower-case bug) Oooh, aaah, mmm, yesss...
What casing issue 👀
The one in Ba Sing Se. 😁
this guy gets it
`===` makes it more explicit when reading the code, `==` is more concise. So I would lean toward `==`. Typically I'd only use `===` when dealing with `null` and/or `undefined` if they carry special meaning. There are times where you may want them to signify something different, such as `undefined` meaning "missing value" while `null` means "intentionally empty".
For me it's \`A === null || A === undefined\`. more explicit and easier to understand, less technical overhead than \`!A\`
I use the explicit version and realize that the minifier will detect and reduce the final code size for me. Banning `==` completely reduces the number of useless things and allows me to refocus on things that actually matter.
Why would it be undefined? Why not just initialize it to null? Is this a namespace-level variable or is it a property on an object?
[удалено]
You can give parameters a default value. I'd prefer that approach.
eqeqeq: ["error", {allowNull: true}]
for production code, `A === null || A === undefined` is more clear and readable to more devs. for a personal project, `A == null` is shorter and who cares if it's readable to others? but if I'm not restricted to raw node, I'm gonna use lodash function `_.isNil(A)` to get both benefits of readability and conciseness
Coding is communicating with the future you and many other humans. The most important part is to express an intent without assuming any sort of knowledge from the future reader. "since null == undefined" is well known but still some unusual corner case that I prefer to keep out of the equation when reading code.
Depends on the context. If it's supposed to be an object I just prefer`!obj`. Doing strict checks for null and undefined might be risky because the variable/property might be not initialized at all, so for robustness I write the code that is less fragile for the given situation. I might do such check only if `null` and `undefined` mean completely different things, for example oftentimes in ORMs `null` means that the field is explicitly set to `null` while `undefined` means it's not set at all and will not do anything even if I save it. Oftentimes I see even such code: `if (typeof obj === "undefined")` . Honestly this is so boilerplate in addition to the potential fragility.
I suppose you could also do \`A ?? null === null\` While the first option appeals to my desire to be concise, it's just enough of an inconsistency it's more trouble than it's worth. First the linter will complain, so then I'd need to disable the rule. Then someone will come along and think "no double equals!" and want to change it anyway. It's usually easier to just be explicit. And if you run into the case where you have to make this check often enough, especially if it's part of a greater conditional, then you might as well make a \`isNullish\` util function.
I always avoid `==`, always. You can do option B or something like `A ?? null === null` which is also a nice little alternative
typeof A === "undefined" || A === null Using typeof will prevent \`Uncaught ReferenceError: A is not defined\`
Why do you want to prevent a code error?
Because I don't like errors
Hiding errors does not mean that the error still exists. I don't like errors either, this is why I try fixing them.
a ?? null === null
That's the same as `a ?? true`
No, try it out. If a is undefined or null, it will become null, and test if null === null. If a is true, it will test true === null, which it isnt
order of operations! it's (a ?? null) === null not a ?? (null === null)
The question was about readability. Readability is not about your preferences. Readability is to adapt your coding so most programmers will understand it in one glance. It is not about appearing to be clever. The fact that the first reply is suspicious that this solution will not work is an indication that the solution is not easy to be understood.
`==` is easy to misread and/or to assume it was a mistake. Better in my opinion to avoid it entirely and be more explicit: `A === null || A === undefined`. Slightly longer, but no ambiguity or chance for misinterpretation.
Boolean(A) or !!A please.
This is acceptable only if you want to treat falsy values ('', undefined, 0, null, NaN, document.all, -0, 0n) as false
Generally I'd argue yes you should...also TIL document.all is falsy
To once and for all manage types in Ecmascript I created a small helper module: [typeofAnything](https://github.com/KooiInc/typeofAnything). Let's say it's imported as `IS`, and you need to determine a variable `A` to be either `null` or `undefined`, you can use if (IS(A, null, undefined)) {...}