5 ms·

Isn't it as simple as: You only need a semi colon if the next line starts with "[" or "(" ?

danneu 11y ago
Yes, at which point the prefixes are easier to notice when they are missing. http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding http://blog.izs.me/post/2353458699/an-open-letter-to-javascr... Either way, no matter your preference, the issue is resolved by having a linter, not by scrutinizing your code for missing semicolons. The OP post feels very dated.
acdha 11y ago
The idea is that leaving out a semicolon saves an almost imperceptible amount of time but requires you to be deeply familiar with the rules of every JavaScript engine, any minifiers/transpilers/etc. which will ever see that code, etc. and also commits you to rigourously applying that logic to every future change. That's where I'd expect this to come up most frequently – someone writes code, tests it, it works and they move on but later someone makes a change and doesn't notice that the original author left a trap for them. It's easy to avoid that in the “ASI is cool” examples but real programs evolve over time and you never want to make maintenance programming harder.
- encoderer 11y ago
  If you're writing idiomatic modern javascript you're using modules -- we no longer have the issue of two JS files being concatenated together in a shared lexical scope. The only rules you need to be familiar with are the 2 I mentioned. In my work, I've never thought about it as "imperceptible" time savings: I worked on a codebase without semi-colons, and then didn't want to go back. It was easier code to work with and write, and the feared downsides never materialized. I still use them to conform with existing code bases or linters that require them, of course, but given the preference..
  - acdha 11y ago
    > It was easier code to work with and write This is the part I'm still having trouble with – hitting ";" at the end of a statement is harder than having to look at the next line and reason about it? I mean, we're talking about a single character on the home row of most keyboards – just how fast are you cranking out code? EDIT: just to be clear, I don't see this as a huge factor either way – a formatter can easily add or remove to your preference – so I surprised by the way ASI proponents talk about it as a big deal. To me it seems like a minor aesthetic preference on the level of “2 spaces or 4?” which doesn't meaningfully change the way you're writing code and is significantly outshone by something like switching to ES6, etc.
    - notmarkus 11y ago
      If you're using an editor to automatically pair your parens/brackets/braces/quotes, you now have to find and navigate to the end of the expression, which could be lines away if you're creating objects and arrays, or calling functions with complex arguments. When coding, my cursor is rarely just "at the end of a statement" on its own. The only way it typically gets there is by me intentionally placing it there. Refactoring is a bigger hassle as well. You may want to use the return of your statement as an argument to some new function. Now the semi has to be removed and added elsewhere. It's not the end of the world, but it's a hassle.
    - encoderer 11y ago
      I never have to "look at the next line and reason about it" -- you simply do not find yourself in a position very often of starting a line with an open brace. I'm not going to list all of the little reasons why I found it more enjoyable and easier to omit the semicolons. If you're interested, try it on a project yourself. Suffice to say, I found several cases where my life was just easier. Here's just one, from the very top of a file. It's easier to add another import to this list: let states = require('../data/states.json') , cloneDeep = require('lodash/cloneDeep')
      - acdha 11y ago
        Again, I have tried this and fail to see any more benefit than, say, changing the indent size in my editor. Personally, I prefer let states = require('../data/states.json'), cloneDeep = require('lodash/cloneDeep'); to let states = require('../data/states.json') , cloneDeep = require('lodash/cloneDeep') but that's an unimportant aesthetic preference. The structure of the code is the same and my experience working with it is fundamentally unchanged. In either case we're talking about a fraction of a percentage of the time it takes to understand what the application is or should be doing. Now compare that to something which actually matters: arrow functions, classes, modules and imports, the newer data structures, generators, etc. In that case, the time spent adopting a new style actually changes the structure of the code you're writing and, hopefully, makes it easier to clearly convey your intention to the next person who works on it.

Yes, at which point the prefixes are easier to notice when they are missing. http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding http://blog.izs.me/post/2353458699/an-open-letter-to-javascr... Either way, no matter your preference, the issue is resolved by having a linter, not by scrutinizing your code for missing semicolons. The OP post feels very dated.

acdha 11y ago

The idea is that leaving out a semicolon saves an almost imperceptible amount of time but requires you to be deeply familiar with the rules of every JavaScript engine, any minifiers/transpilers/etc. which will ever see that code, etc. and also commits you to rigourously applying that logic to every future change. That's where I'd expect this to come up most frequently – someone writes code, tests it, it works and they move on but later someone makes a change and doesn't notice that the original author left a trap for them. It's easy to avoid that in the “ASI is cool” examples but real programs evolve over time and you never want to make maintenance programming harder.

encoderer 11y ago
If you're writing idiomatic modern javascript you're using modules -- we no longer have the issue of two JS files being concatenated together in a shared lexical scope. The only rules you need to be familiar with are the 2 I mentioned. In my work, I've never thought about it as "imperceptible" time savings: I worked on a codebase without semi-colons, and then didn't want to go back. It was easier code to work with and write, and the feared downsides never materialized. I still use them to conform with existing code bases or linters that require them, of course, but given the preference..
- acdha 11y ago
  > It was easier code to work with and write This is the part I'm still having trouble with – hitting ";" at the end of a statement is harder than having to look at the next line and reason about it? I mean, we're talking about a single character on the home row of most keyboards – just how fast are you cranking out code? EDIT: just to be clear, I don't see this as a huge factor either way – a formatter can easily add or remove to your preference – so I surprised by the way ASI proponents talk about it as a big deal. To me it seems like a minor aesthetic preference on the level of “2 spaces or 4?” which doesn't meaningfully change the way you're writing code and is significantly outshone by something like switching to ES6, etc.
  - notmarkus 11y ago
    If you're using an editor to automatically pair your parens/brackets/braces/quotes, you now have to find and navigate to the end of the expression, which could be lines away if you're creating objects and arrays, or calling functions with complex arguments. When coding, my cursor is rarely just "at the end of a statement" on its own. The only way it typically gets there is by me intentionally placing it there. Refactoring is a bigger hassle as well. You may want to use the return of your statement as an argument to some new function. Now the semi has to be removed and added elsewhere. It's not the end of the world, but it's a hassle.
  - encoderer 11y ago
    I never have to "look at the next line and reason about it" -- you simply do not find yourself in a position very often of starting a line with an open brace. I'm not going to list all of the little reasons why I found it more enjoyable and easier to omit the semicolons. If you're interested, try it on a project yourself. Suffice to say, I found several cases where my life was just easier. Here's just one, from the very top of a file. It's easier to add another import to this list: let states = require('../data/states.json') , cloneDeep = require('lodash/cloneDeep')
    - acdha 11y ago
      Again, I have tried this and fail to see any more benefit than, say, changing the indent size in my editor. Personally, I prefer let states = require('../data/states.json'), cloneDeep = require('lodash/cloneDeep'); to let states = require('../data/states.json') , cloneDeep = require('lodash/cloneDeep') but that's an unimportant aesthetic preference. The structure of the code is the same and my experience working with it is fundamentally unchanged. In either case we're talking about a fraction of a percentage of the time it takes to understand what the application is or should be doing. Now compare that to something which actually matters: arrow functions, classes, modules and imports, the newer data structures, generators, etc. In that case, the time spent adopting a new style actually changes the structure of the code you're writing and, hopefully, makes it easier to clearly convey your intention to the next person who works on it.