3 ms·

For me the reason to always use semicolons is the same reason I always use ===. There are just too many rules to remember and I've got more important things to

• mistermann 16y ago
  Maybe an inappropriate question, but could you explain the significance of === to the unenlightened amongst us?
  • nene 16y ago
    Comparing with === does not perform type coercion, while == does and the rules for type coercion in JavaScript are even more funky than for semicolon insertion.
  • adolph 16y ago
    The standard equality operators (== and !=) compare two operands without regard to their type. The strict equality operators (=== and !==) perform equality comparisons on operands of the same type. Use strict equality operators if the operands must be of a specific type as well as value or if the exact type of the operands is important. Otherwise, use the standard equality operators, which allow you to compare the identity of two operands even if they are not of the same type. So: (1 == '1') is true;(1 === '1') is false. https://developer.mozilla.org/en/JavaScript/Reference/Operators/Comparison_Operators https://developer.mozilla.org/en/JavaScript/Reference/Operat...
    • Groxx 16y ago
      And, strangely, (NaN === NaN) is false. Gotta use isNaN(NaN).
      • raganwald 16y ago
        That's the only part of Javascript's ==/=== dichotomy that I like. It maps directly to the way NULL works in SQL. NULL means "I don't know what this is," so two unknown things can't be tested for equality because you don't know what they are. NaN is a similar concept. You tried to make a number, it borked, how can you test one bork against another for equality?
        • Groxx 16y ago
          I hadn't thought of it that way (comparing borks, not sql null); it does make some sense in that light (though then you should be able to compare the same NaN in two variables...). Though that undefined === undefined works, and so does Infinity === Infinity doesn't make as much sense when thought of that way; infinities aren't all equal, and undefined isn't a single kind of value that it makes sense to compare as if it were. And to counteract the sql null viewpoint, (null === null) works. Also: var x = parseInt("a"); x === NaN // false alert(x); // "NaN" doesn't make a whole lot of sense. isNaN() performs the exact same thing that === NaN implies. Especially as: {}.x // undefined {x:undefined}.x // undefined for(prop in {x:undefined}) alert(prop); // displays "x" {}.x === {x:undefined}.x // true Meh. It's a weird language. Not intending to shoot you down; just spilling my brain into a textbox.
      • cosbynator 16y ago
        That's to match IEEE-754, x==x will return false if x is a NaN in just about every language I can think of.
    • cobbal 16y ago
      An interesting property of this is that == isn't transitive '' == 0 // true 0 == '0' // true '0' == '' // false
• scott_s 16y ago
  I think this is the most important point: if understanding when or when not to use semicolons requires a subtle understanding of the language grammar, then terminating every statement has a cognitive cost. This cost adds to coding friction. I don't personally use JS, but I do use C/C++ and Python. I prefer Python's syntax because I find it clean. Most of my work is in semicolon-and-brace languages, so I'm clearly familiar with that style, too. But were I to code in JS, I'd always use semicolons, because that's easier than constantly asking myself, "Do I need a semicolon or not?" As an analogy, I use my turn signal every time I make a turn in my car. Every time. Even if I'm in an empty parking lot. That way, I never have to decide, "Should I use my turn signal?" It's just automatic. It reduces the amount of thought I have to put into things that don't actually matter.
  • deleted 16y ago
    [deleted]