6 ms·

"...but you have to be aware of some edge cases" There's the reason.

bryanlarsen 15y ago
The point of the article is that Python has very similar edge cases yet nobody advocates the use of semicolons in Python.
- veyron 15y ago
  Because python handles them in a way that people would expect python to handle them
  - notSorella 15y ago
    And where would JavaScript not handle them in a way people don't expect them to be handled? Comparing Python's handling of semicolons with JavaScript's ASI, you get the following: -- End of statements Python and JavaScript: Ends with either a new line or a semicolon. -- Line joining Python: whitespace strict, so lines must be either explicitly joined through the `\' escape character, or put inside a parenthesized expression, which ignores whitespace. JavaScript: non-whitespace strict, so lines don't need to be explicitly joined. Statements may be continued by starting the following line with a continuation token (one of: `[ ( + - /') -- Exceptions Python: Parenthesized expressions use a different parser state (ie.: whitespace strict vs non-whitespace strict) JavaScript: restricted production grammar usually have optional expressions following them, and since they are a valid statement on their own, the statement will be ended with a new line. So, the related information must start in the same line. Restricted productions are: return, break and continue; Post-fix and prefix operators are included as restricted productions for readability's sake. I fail to see how that's difficult to remember, or how that's insanely more complex than Python's rules...
    - sid0 15y ago
      Yes, the line joining is precisely where people trip up, the classic example being return { foo: bar }
      - deleted 15y ago
        [deleted]
      - notSorella 15y ago
        That's not a problem with the line joining stuff. Both `return' and `{ foo: bar }' are ENTIRE VALID statements in their own right. returnStmt ::= "return" [ expression ] (";" or EOL) Note that expression is optional, so it's the choice of `return' by itself being a valid statement on its own that "causes problems". Plus, this is not really a problem that can be solved by simply putting semicolons everywhere. You can't change the parser rules by including or not semicolons. Also, same thing with break/continue: breakStmt ::= "break" [ label ] (";" or EOL) continueStmt ::= "continue" [ label ] (";" or EOL)
        cdsanchez 15y ago
        `return` may be a valid statement but an object literal is not. A standalone object literal would likely be interpreted as a block and would throw a syntax error unless it were a simple identifier and a statement `{ foo: <statement> }`, in which case it would not interpret it as an object but exactly what it is, a label and a statement. This is why JSON parsers which use eval must first wrap the object literal with parens, to make it an expression rather than a statement.
        notSorella 15y ago
        Never said it was an object literal eh. Object literals can only occur inside expressions, that's pretty well defined in the JavaScript AST too, which is described to the utmost detail in the ECMAScript specs. The thing is: - `return` alone is a valid statement in its own. - The parser just need to use a simple lookahead to decide whether the next line is part of the previous statement. - The parser DON'T change the meaning of your programs. All that's beside that is a matter of taste. Whether use semicolons or not is up to what sits better with each person. I'm just arguing against the silly and incorrect "technical" arguments against it.
    - agscala 15y ago
      It's mostly because of the way JavaScript handles your 'line joining' point. It's not great, and it's easy to shoot yourself in the foot.
      - notSorella 15y ago
        I really don't see any problem with the way JavaScript handles it. "Unless the following line can be part of the preceding statement, end the current statement" is a pretty natural thing to me. But well, I guess that's a matter of taste, and you can't really discuss that...
einaregilsson 15y ago
But isn't that part of learning any language? There are plenty of weird edge cases in other languages but we get used to them. Basically this boils down to: "When you have a single statement, that stretches out over more than one line, but those lines are legal statements on their own, then it won't work like you want it to" I would guess that the number of statements that stretch out over many lines are a very small part of the overall number of statements for most code. But it just seems like most developers think that javascript might insert semicolons all over the place. Which it won't, the rules are clear once you learn them.
- einaregilsson 15y ago
  Ahem, maybe not as clear as I thought, since I found a few other edge cases I didn't know of in this excellent article: Best article I've read on the subject: http://inimino.org/~inimino/blog/javascript_semicolons http://inimino.org/~inimino/blog/javascript_semicolons
- felipemnoa 15y ago
  Or, just add a semicolon and keep it simple. Why risk it? KISS at work.
  - einaregilsson 15y ago
    There are two possibilities: 1. Prefix lines that start with punctuation, specifically [(-+/ with a ;. Then omit them everywhere else. Lines that start with punctuation are a tiny subset of all lines generally. 2. Postfix every line with a ;, "just in case" I can't see how nr. 1 is harder. And in case 2 you don't actually put ; at the end of every line, you don't put them after {} blocks for example, so it's not like it's somehow easier to remember. "Because we're used to doing it that way" is a reason I guess, but not a great one in my opinion.
sjs 15y ago
Isn't it really only one edge case, that being punctuation at the beginning of a line?
drivebyacct2 15y ago
But using semicolons doesn't eliminate those edge cases. Those are just places where auto-semicolon-insert fails to standup to what humans perceive to be the "right" behavior. Semicolons or no, if you put a newline character between return and the retval, you will get the "wrong" behavior.

The point of the article is that Python has very similar edge cases yet nobody advocates the use of semicolons in Python.

veyron 15y ago
Because python handles them in a way that people would expect python to handle them
- notSorella 15y ago
  And where would JavaScript not handle them in a way people don't expect them to be handled? Comparing Python's handling of semicolons with JavaScript's ASI, you get the following: -- End of statements Python and JavaScript: Ends with either a new line or a semicolon. -- Line joining Python: whitespace strict, so lines must be either explicitly joined through the `\' escape character, or put inside a parenthesized expression, which ignores whitespace. JavaScript: non-whitespace strict, so lines don't need to be explicitly joined. Statements may be continued by starting the following line with a continuation token (one of: `[ ( + - /') -- Exceptions Python: Parenthesized expressions use a different parser state (ie.: whitespace strict vs non-whitespace strict) JavaScript: restricted production grammar usually have optional expressions following them, and since they are a valid statement on their own, the statement will be ended with a new line. So, the related information must start in the same line. Restricted productions are: return, break and continue; Post-fix and prefix operators are included as restricted productions for readability's sake. I fail to see how that's difficult to remember, or how that's insanely more complex than Python's rules...
  - sid0 15y ago
    Yes, the line joining is precisely where people trip up, the classic example being return { foo: bar }
    - deleted 15y ago
      [deleted]
    - notSorella 15y ago
      That's not a problem with the line joining stuff. Both `return' and `{ foo: bar }' are ENTIRE VALID statements in their own right. returnStmt ::= "return" [ expression ] (";" or EOL) Note that expression is optional, so it's the choice of `return' by itself being a valid statement on its own that "causes problems". Plus, this is not really a problem that can be solved by simply putting semicolons everywhere. You can't change the parser rules by including or not semicolons. Also, same thing with break/continue: breakStmt ::= "break" [ label ] (";" or EOL) continueStmt ::= "continue" [ label ] (";" or EOL)
      - cdsanchez 15y ago
        `return` may be a valid statement but an object literal is not. A standalone object literal would likely be interpreted as a block and would throw a syntax error unless it were a simple identifier and a statement `{ foo: <statement> }`, in which case it would not interpret it as an object but exactly what it is, a label and a statement. This is why JSON parsers which use eval must first wrap the object literal with parens, to make it an expression rather than a statement.
        notSorella 15y ago
        Never said it was an object literal eh. Object literals can only occur inside expressions, that's pretty well defined in the JavaScript AST too, which is described to the utmost detail in the ECMAScript specs. The thing is: - `return` alone is a valid statement in its own. - The parser just need to use a simple lookahead to decide whether the next line is part of the previous statement. - The parser DON'T change the meaning of your programs. All that's beside that is a matter of taste. Whether use semicolons or not is up to what sits better with each person. I'm just arguing against the silly and incorrect "technical" arguments against it.
  - agscala 15y ago
    It's mostly because of the way JavaScript handles your 'line joining' point. It's not great, and it's easy to shoot yourself in the foot.
    - notSorella 15y ago
      I really don't see any problem with the way JavaScript handles it. "Unless the following line can be part of the preceding statement, end the current statement" is a pretty natural thing to me. But well, I guess that's a matter of taste, and you can't really discuss that...

einaregilsson 15y ago

But isn't that part of learning any language? There are plenty of weird edge cases in other languages but we get used to them. Basically this boils down to: "When you have a single statement, that stretches out over more than one line, but those lines are legal statements on their own, then it won't work like you want it to" I would guess that the number of statements that stretch out over many lines are a very small part of the overall number of statements for most code. But it just seems like most developers think that javascript might insert semicolons all over the place. Which it won't, the rules are clear once you learn them.

einaregilsson 15y ago
Ahem, maybe not as clear as I thought, since I found a few other edge cases I didn't know of in this excellent article: Best article I've read on the subject: http://inimino.org/~inimino/blog/javascript_semicolons http://inimino.org/~inimino/blog/javascript_semicolons
felipemnoa 15y ago
Or, just add a semicolon and keep it simple. Why risk it? KISS at work.
- einaregilsson 15y ago
  There are two possibilities: 1. Prefix lines that start with punctuation, specifically [(-+/ with a ;. Then omit them everywhere else. Lines that start with punctuation are a tiny subset of all lines generally. 2. Postfix every line with a ;, "just in case" I can't see how nr. 1 is harder. And in case 2 you don't actually put ; at the end of every line, you don't put them after {} blocks for example, so it's not like it's somehow easier to remember. "Because we're used to doing it that way" is a reason I guess, but not a great one in my opinion.

sjs 15y ago

Isn't it really only one edge case, that being punctuation at the beginning of a line?

drivebyacct2 15y ago

But using semicolons doesn't eliminate those edge cases. Those are just places where auto-semicolon-insert fails to standup to what humans perceive to be the "right" behavior. Semicolons or no, if you put a newline character between return and the retval, you will get the "wrong" behavior.