5 ms·

Can someone please provide a valid, technical reason for not using semicolons other than "it doesn't say I hafta so I'm not gonna!" (that quoted bit should be r

Can someone please provide a valid, technical reason for not using semicolons other than "it doesn't say I hafta so I'm not gonna!" (that quoted bit should be read as if a 5 year old throwing a tantrum was saying it)

tomjen3 14y ago
Yes, but I am not going to waste my time with it when you are not willing to debate it in good faith.
- pavel_lishin 14y ago
  I'm willing to, please don't withhold enlightenment to spite one guy.
  - tomjen3 14y ago
    I write Javascript for a living, and the code standard requires semicolons. Anyway variables in javascript have function scope, so two variables with the same name in the same function always refer to the same value, even if declared twice. As a result I like to write all the variable statements at the top of each function, all in one var statement. The problem then becomes that you write var a, b, c, d; and then later want to add variable e. If you aren't careful you might accidentally write var a, b, c, d; e; if you do that, the program may still work but e now has global scope. This results in nearly impossible to find bugs that may only happen if the function is recursive or it is called (perhaps indirectly) by some other function with a similarily named variable. Considering that semicolons insertion mostly works, and the other can be a huge pain in the rear end, I can understand why people would want to skip the semicolons.
    - tedunangst 14y ago
      If you aren't careful, you might accidentally write var a, b, c, d, r;
    - thedaniel 14y ago
      The JS interpreter shares your preference of writing all var declarations at the top - in fact, at interpretation time they will be "hoisted" to the top of the scope. In other words: foo() var bar = 1; is actually run as var bar; foo(); bar = 1;
      - tomjen3 14y ago
        True, and that was part of what I was trying to articulate.
    - DrJokepu 14y ago
      I think it's generally a good idea to avoid declaring multiple variables in the same line (unless you have a very good reason). The space you "save" isn't worth the maintainability penalty. This is a habit I have from C where int* a, b declares "a" as ( int* ) and b as ( int ). Instead, I just write int *a; int *b;
      - lmm 14y ago
        If you get in the habit of writing the * next to the variable then you can't make the mistake. int *a, b, c[]; perfectly clear.
    - bmuon 14y ago
      Strict mode should save you from a lot of those. (function () { 'use strict'; var a = 1; b = 2; }()); // ReferenceError: b is not defined
    - OriginalSyn 14y ago
      But this is a simple error caught by js(h/l)int. And it's especially easy to spot if you just declare each var one after another: var a, b, c, d; e; Then your editor (which you've a integrated a linter... right?) will protested: yourJsFile.js |5 warning| 'e' was used before it was defined. And if you have a global by the same name you'll see: yourJsFile.js |5 warning| Expected an assignment or function call and instead saw an expression. Granted, if you assign it a default value then, yes you're going to have a bad time. But if you follow the white spacing rules of jsLint it will catch the obvious error.
mdavidn 14y ago
JavaScript minifiers use commas to avoid braces in control statements. The following two statements are functionally identical. Apparently the Closure Compiler goes overboard and just uses commas everywhere, even when the comma offers no length advantage over semicolons. if (a) { b(); c() } if (a) b(), c()
- sjwright 14y ago
  Can someone please provide a valid, technical reason for not using braces other than "it reduces my file sizes by one percent prior to gzipping zomg!"
  - mistercow 14y ago
    But reducing file sizes by one percent, if done by an automatic tool, is a perfectly worthwhile reason. You don't need any other justification. Or you wouldn't, of course, if it weren't for some browsers being broken and unable to handle it.
    - greghinch 14y ago
      Ok, but any front-end engineer worth their salt should be used to the fact that the browser will never be a perfect implementation environment and be willing to adapt around known issues to produce functional code that works for your users. They aren't going to notice that 1% file size. They are going to notice your page not working.
      - mistercow 14y ago
        Yes of course working in every browser should be the priority, but it is only obvious that this particular optimization would cause a problem in hindsight. As for "they aren't going to notice that 1% file size", you could keep saying that about small optimization after small optimization until your compiler's output is 10% bigger than the competition's, at which point you will start losing significant user base.
      - 14y ago
hhhhhhhhh 14y ago
in vim A (capital!) jumps to the end of the line in insert mode and semicolons get in the way this is literally the only objective reason i have ever seen for using/not using semicolons
- OriginalSyn 14y ago
  Hacked this together in a couple seconds, there is probably a better way: nnoremap A :call EndOfLine()<CR>a fu! EndOfLine() normal $ if getline(".")[col(".")-1] == ';' normal h endif endfunction

tomjen3 14y ago

Yes, but I am not going to waste my time with it when you are not willing to debate it in good faith.

pavel_lishin 14y ago
I'm willing to, please don't withhold enlightenment to spite one guy.
- tomjen3 14y ago
  I write Javascript for a living, and the code standard requires semicolons. Anyway variables in javascript have function scope, so two variables with the same name in the same function always refer to the same value, even if declared twice. As a result I like to write all the variable statements at the top of each function, all in one var statement. The problem then becomes that you write var a, b, c, d; and then later want to add variable e. If you aren't careful you might accidentally write var a, b, c, d; e; if you do that, the program may still work but e now has global scope. This results in nearly impossible to find bugs that may only happen if the function is recursive or it is called (perhaps indirectly) by some other function with a similarily named variable. Considering that semicolons insertion mostly works, and the other can be a huge pain in the rear end, I can understand why people would want to skip the semicolons.
  - tedunangst 14y ago
    If you aren't careful, you might accidentally write var a, b, c, d, r;
  - thedaniel 14y ago
    The JS interpreter shares your preference of writing all var declarations at the top - in fact, at interpretation time they will be "hoisted" to the top of the scope. In other words: foo() var bar = 1; is actually run as var bar; foo(); bar = 1;
    - tomjen3 14y ago
      True, and that was part of what I was trying to articulate.
  - DrJokepu 14y ago
    I think it's generally a good idea to avoid declaring multiple variables in the same line (unless you have a very good reason). The space you "save" isn't worth the maintainability penalty. This is a habit I have from C where int* a, b declares "a" as ( int* ) and b as ( int ). Instead, I just write int *a; int *b;
    - lmm 14y ago
      If you get in the habit of writing the * next to the variable then you can't make the mistake. int *a, b, c[]; perfectly clear.
  - bmuon 14y ago
    Strict mode should save you from a lot of those. (function () { 'use strict'; var a = 1; b = 2; }()); // ReferenceError: b is not defined
  - OriginalSyn 14y ago
    But this is a simple error caught by js(h/l)int. And it's especially easy to spot if you just declare each var one after another: var a, b, c, d; e; Then your editor (which you've a integrated a linter... right?) will protested: yourJsFile.js |5 warning| 'e' was used before it was defined. And if you have a global by the same name you'll see: yourJsFile.js |5 warning| Expected an assignment or function call and instead saw an expression. Granted, if you assign it a default value then, yes you're going to have a bad time. But if you follow the white spacing rules of jsLint it will catch the obvious error.

mdavidn 14y ago

JavaScript minifiers use commas to avoid braces in control statements. The following two statements are functionally identical. Apparently the Closure Compiler goes overboard and just uses commas everywhere, even when the comma offers no length advantage over semicolons. if (a) { b(); c() } if (a) b(), c()

sjwright 14y ago
Can someone please provide a valid, technical reason for not using braces other than "it reduces my file sizes by one percent prior to gzipping zomg!"
- mistercow 14y ago
  But reducing file sizes by one percent, if done by an automatic tool, is a perfectly worthwhile reason. You don't need any other justification. Or you wouldn't, of course, if it weren't for some browsers being broken and unable to handle it.
  - greghinch 14y ago
    Ok, but any front-end engineer worth their salt should be used to the fact that the browser will never be a perfect implementation environment and be willing to adapt around known issues to produce functional code that works for your users. They aren't going to notice that 1% file size. They are going to notice your page not working.
    - mistercow 14y ago
      Yes of course working in every browser should be the priority, but it is only obvious that this particular optimization would cause a problem in hindsight. As for "they aren't going to notice that 1% file size", you could keep saying that about small optimization after small optimization until your compiler's output is 10% bigger than the competition's, at which point you will start losing significant user base.
    - 14y ago

hhhhhhhhh 14y ago

in vim A (capital!) jumps to the end of the line in insert mode and semicolons get in the way this is literally the only objective reason i have ever seen for using/not using semicolons

OriginalSyn 14y ago
Hacked this together in a couple seconds, there is probably a better way: nnoremap A :call EndOfLine()<CR>a fu! EndOfLine() normal $ if getline(".")[col(".")-1] == ';' normal h endif endfunction