3 ms·

The same for “== considered harmful”. I scanned the entire comparison table and the only unobvious or error-prone cases are those you never really do in program

• emteycz 5y ago
  undefined and null sometimes make problems. IMHO it's good that undefined == null but some people don't realize.
  • wruza 5y ago
    I agree. If native apis didn’t return nulls in some cases, and undefined was named “undef” at least, null could be ditched. But then again, it’s only because js has no bad habit of treating the same of non-existence and undefinedness^. If not json (which has no undefined), we could ditch null. But it’s there and with === it leads to either object.someField === null || object.someFeild === undefined madness, or to a potential error if a programmer thinks that null can not be there. We could do an exception for null === undefined, but it’s against its spirit and will not be accepted. ^ languages that treat non-existent key as undefined are usually doomed to introduce Null atom in some form, or to work around that limitation constantly in metaprogramming
    • blacktriangle 5y ago
      null and undefined is one of the things Javascript actually got right imo. Undefined is what lets Javascript turn what other dynamic language would throw as a runtime error into a value. "I do not have a definition for the thing you want" and "the thing you want is known to be unknown" are two totally different concepts that languages with only null to lean on must collapse into a single concept.
      • Sankozi 5y ago
        The problem is undefined is used in places null makes much more sense (like a result of the find function). I follow the rule to never use null and convert to/from undefined if needed by some library.
        • blacktriangle 5y ago
          Leave it to javascript to pull defeat from the jaws of victory.
      • Jasper_ 5y ago
        I've never found this to be a useful difference in practice. Also, JavaScript really doesn't use it correctly to begin with. Arrays are a mess. Like the poster below, I usually cast to one of them, except I cast to null.
• Liquid_Fire 5y ago
  > the only unobvious or error-prone cases are those you never really do in programming. You never do them on purpose. The problem is when you do them by accident because of a mistake in your code, and the error slips through unnoticed, doing the wrong thing. > weak-typed comparisons like in perl Perl has separate operators for working on strings vs numbers, so you are always explicit about performing a numerical vs string comparison etc. Not so for JavaScript.
  • denton-scratch 5y ago
    Agree. The tests are silly, but each test highlights a gotcha that you might bump into while debugging some horrible heap of legacy code.
  • wruza 5y ago
    you are always explicit about performing a numerical vs string comparison But the values which you compare do not have to be of the same type, and it does not end at scalars (which are really ephemeral in their exact typing even in native API, see perlapi). Basically it has two flavors of ==, each with its own preferred coercion. Perl also has contexts, e.g. boolean and scalar which can operate on lists and hashes (@list == 5). While the form is different, semantics are similar. The problem is when you do them by accident because of a mistake in your code, and the error slips through unnoticed, doing the wrong thing If your string array contains some [[0]] by accident, I’d say there is not much left to do anyway. === doesn’t report this either, it only has narrower trueness, which may decrease or increase an error surface depending on how your conditions are spelled. And to be clear, I’m not arguing against using === in places where identity^ or strict equality check is necessary or desired (you may desire it most of the times and that’s valid). My concern is that (a) everyone blames == anywhere, for completely zealous reasons, (b) I have to type a poem to test for null and calm down someone’s anxiety. ^ I know it’s not exactly identity, but is close enough for practical purposes