3 ms·

I refuse to use semi-colons in TS/JS, unless that conflicts with existing code standards. I feel like it's as if I'm using semi-colons in Go. This can easily be

by ezekg 8y ago

I refuse to use semi-colons in TS/JS, unless that conflicts with existing code standards. I feel like it's as if I'm using semi-colons in Go. This can easily be avoided by writing clearer code.

ezekg 8y ago
Relevant: https://standardjs.com/rules.html#semicolons https://standardjs.com/rules.html#semicolons (hint: no semi-colons!)
- joshuamorton 8y ago
  Which also recommends ;(function () { window.alert('ok') }()) Which, just, eww. Just use semicolons. Everywhere, always. Then you can treat JS's parsing rules as the same as every other language, and not normally like every other language except when a line begins with one of a select set of magical charaters that need to be prepended with `;` for unclear reasons. Just end lines with `;`.
  - Klathmon 8y ago
    >Just end lines with `;`. But that's not always the solution, you still need to know when ASI kicks in and when it doesn't. "just end lines with ;" isn't true in multi-line arrays, in multi-line objects, and a ton of other situations where a semi at the end of the line is a syntax error. And while i'm sure you know that and didn't actually mean "every" line, it just goes to show that you already have the knowledge of when to add them and when not to. But that knowledge is learned, and it isn't a simple rule by any means. For example, the following code is probably not going to do what many beginners think it will do: return [ 1, 2, 3, ]; Because the JS engine will insert a semicolon right after the return, and you will basically get `return undefined;` as the result. Semicolons at the end of lines or not, you still need to understand when they are inserted and when they aren't. The real solution is to use a linter which will check these cases for you. I don't care if you use them or don't, just make sure something else enforces it.
    - joshuamorton 8y ago
      You're absolutely correct. Jey provided the better phrasing of my comment: Use `;` to end a statement. The point I'm making is more bias toward using `;`, even when not strictly "necessary". This brings JS's statement parsing in line with most other languages. And yes, absolutely use a linter.
      - Klathmon 8y ago
        Or you can do what a past coworker did. We settled on standard.js for our linting in a project, and they don't use semicolons. The coworker hated this, so he setup his editor to auto-format into his preferred style on load, then on save use the auto-format option in standard.js to save it as the format that we agreed on in the repo. He only ever worked with his favorite layout, and we worked with ours! I'm not a big fan of holy wars in programming, i'm fine with either even if I do prefer one style over the other, but at the end of the day I just hope that everyone involved understands that it's just a preference thing for the most part. Linters will catch the edge cases for both styles, and if you really can't adapt to using or not using semicolons in javascript, there are probably other issues at play.
        ezekg 8y ago
        This made me laugh out loud. I identify with the sentiment (I can get pretty pedantic about how code looks), but I wouldn't take it to that extreme.
  - ezekg 8y ago
    Which also states this, directly under that "bad" example: Note: If you're often writing code like this, you may be trying to be too clever. Clever short-hands are discouraged, in favor of clear and readable expressions, whenever possible. Instead of this: ;[1, 2, 3].forEach(bar) This is strongly preferred: var nums = [1, 2, 3] nums.forEach(bar)
    - Retra 8y ago
      The irony is that building a language which avoids semicolons by automatically inserting them is arguably taking a clever short-hand in favor of unclear and ambiguous expressions.
  - jey 8y ago
    Yeah, use ";" to denote the end of a statement. Or if you're serious, switch to BuckleScript and reduce all your side-effecting expressions down to unit. (Fully eliminates unhandled promise bugs, for one thing.)
  - adrianhel 8y ago
    Or just don't use classic IIFEs void function () { window.alert('ok') }() So much cleaner. Or better yet, stop using IIFEs. Unless you need IE11 support and can't transpile your code there is absolutely no need. { let x = 42 } console.log(typeof x) // undefined

by ezekg 8y ago

I refuse to use semi-colons in TS/JS, unless that conflicts with existing code standards. I feel like it's as if I'm using semi-colons in Go. This can easily be avoided by writing clearer code.

ezekg 8y ago

Relevant: https://standardjs.com/rules.html#semicolons https://standardjs.com/rules.html#semicolons (hint: no semi-colons!)

joshuamorton 8y ago
Which also recommends ;(function () { window.alert('ok') }()) Which, just, eww. Just use semicolons. Everywhere, always. Then you can treat JS's parsing rules as the same as every other language, and not normally like every other language except when a line begins with one of a select set of magical charaters that need to be prepended with `;` for unclear reasons. Just end lines with `;`.
- Klathmon 8y ago
  >Just end lines with `;`. But that's not always the solution, you still need to know when ASI kicks in and when it doesn't. "just end lines with ;" isn't true in multi-line arrays, in multi-line objects, and a ton of other situations where a semi at the end of the line is a syntax error. And while i'm sure you know that and didn't actually mean "every" line, it just goes to show that you already have the knowledge of when to add them and when not to. But that knowledge is learned, and it isn't a simple rule by any means. For example, the following code is probably not going to do what many beginners think it will do: return [ 1, 2, 3, ]; Because the JS engine will insert a semicolon right after the return, and you will basically get `return undefined;` as the result. Semicolons at the end of lines or not, you still need to understand when they are inserted and when they aren't. The real solution is to use a linter which will check these cases for you. I don't care if you use them or don't, just make sure something else enforces it.
  - joshuamorton 8y ago
    You're absolutely correct. Jey provided the better phrasing of my comment: Use `;` to end a statement. The point I'm making is more bias toward using `;`, even when not strictly "necessary". This brings JS's statement parsing in line with most other languages. And yes, absolutely use a linter.
    - Klathmon 8y ago
      Or you can do what a past coworker did. We settled on standard.js for our linting in a project, and they don't use semicolons. The coworker hated this, so he setup his editor to auto-format into his preferred style on load, then on save use the auto-format option in standard.js to save it as the format that we agreed on in the repo. He only ever worked with his favorite layout, and we worked with ours! I'm not a big fan of holy wars in programming, i'm fine with either even if I do prefer one style over the other, but at the end of the day I just hope that everyone involved understands that it's just a preference thing for the most part. Linters will catch the edge cases for both styles, and if you really can't adapt to using or not using semicolons in javascript, there are probably other issues at play.
      - ezekg 8y ago
        This made me laugh out loud. I identify with the sentiment (I can get pretty pedantic about how code looks), but I wouldn't take it to that extreme.
- ezekg 8y ago
  Which also states this, directly under that "bad" example: Note: If you're often writing code like this, you may be trying to be too clever. Clever short-hands are discouraged, in favor of clear and readable expressions, whenever possible. Instead of this: ;[1, 2, 3].forEach(bar) This is strongly preferred: var nums = [1, 2, 3] nums.forEach(bar)
  - Retra 8y ago
    The irony is that building a language which avoids semicolons by automatically inserting them is arguably taking a clever short-hand in favor of unclear and ambiguous expressions.
- jey 8y ago
  Yeah, use ";" to denote the end of a statement. Or if you're serious, switch to BuckleScript and reduce all your side-effecting expressions down to unit. (Fully eliminates unhandled promise bugs, for one thing.)
- adrianhel 8y ago
  Or just don't use classic IIFEs void function () { window.alert('ok') }() So much cleaner. Or better yet, stop using IIFEs. Unless you need IE11 support and can't transpile your code there is absolutely no need. { let x = 42 } console.log(typeof x) // undefined