Although I understand that this rule might be (too) opinionated, but I never met a developer yet that thinks the use of null in Javascript/Typescript is a good practice. They all prefer the use of undefined, and undefined only.
Triggered by (typescript:S6606 incorrect suggestion - mixes up null and undefined) which is just another example that shows how confusing the use of both null and undefined are. By avoiding the use of null (or treating it the same way as undefined) code will be cleaner, and easier to reason about.
Thank you for good pointers and links. I clearly understand the idea behind not using null if it has the same meaning as undefined. In my case x was an optional method argument, having the following meanings: undefined - value not specified at all, use default behavior (eg load defaults from DB),
value - use the value provided null - the value needs to be deleted.
The method was preparing PATCH request, and explicit null value was treated differently (deletion) from missing value (not touching at all). For data structures without arrays such approach has been beneficial. Using eg rfc6902 seems too much overhead. But I’d be glad to hear good architectural patterns about PATCH requests.
I would argue that you should communicate deletion differently. The whole point is that it is confusing when null and undefined have a different meaning.
Yeah, understood. Anyways, it was a side topic. Back to my initial question about rule S6606. It clearly states This rule reports when disjunctions (||) and conditionals (?) can be safely replaced with coalescing (??). Imho it should
apply only when it actually IS safe and without any side effects, regardless how stupid the code is, or
explicitly warn the user that it may change the semantics.
Also, maybe a new rule should be created (at least for Typescript, but preferably for JS, too) suggesting developers to not use null at all? Ie, highlight every explicit null usage in the code.
As you might have missed, you’re responding to a topic that exactly suggests the creation of a rule that should warn developers once they try to use null differently then that undefined.
Personally, I have to disagree: such rule could have way too many FP. There are even APIs that rely on the use of null. Also, I don’t see the negatives of null as long as there are team code conventions followed by all members and they agree on certain usages of null.
This rule is indeed opinionated, and FP’s can be a real showstopper. But when teams decide they have to rely on null and undefined being different an disable the rule, than for those who want this rule (and I guess, I’m not the only one) would be happy too.