Hacker News Reader

Comment by nene | Hacker News Reader

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 keep in my mind.

It's also good to have your JavaScript look like the JavaScript most other people write. I have practiced many different coding conventions in my life, and I don't really hate none of them, but the thing I do dislike is context-switching between different conventions in different projects. We already have tabs v/s spaces and several other possible differences. It would be nice to exclude the choice for semicolon placement from that list.

I do agree with the author in one point: you should understand how automatic semicolon insertion works. And then make up your mind about it. Don't just blindly follow anybodys advice.

View on HN

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.

Maybe an inappropriate question, but could you explain the significance of === to the unenlightened amongst us?

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.

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/Operat...

And, strangely, (NaN === NaN) is false. Gotta use isNaN(NaN).

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?

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.

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.

An interesting property of this is that == isn't transitive

  '' == 0 // true
  0 == '0' // true
  '0' == '' // false

Reply on news.ycombinator.com