Hacker News Reader

Comment by greghinch | Hacker News Reader

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)

View on HN

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()

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!"

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.

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.

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.

A 1% reduction in output at Twitter's scale isn't as paltry as you might assume. Engineering decisions are made for both server-side and client-side reasons.

You're making a blanket statement about Twitter developing bad code because of a recent bug. It will be fixed.

Yes, saving 1% of a few million requests a day is not a trivial savings.

I kind of wonder about that reasoning, though. I mean, no it's not trivial if you imagine having to foot the bill for it yourself, but proportional to the kind of money Twitter is dealing with, it's, well, still just 1% of a JS file.

But I don't think we need to think of it in terms of Twitter's scale at all. The point is that saving 1% for basically free, is saving 1% for basically free, and that's worthwhile no matter how big you are. On its own, it's a drop in the bucket, but the cumulative effect of many small low-opportunity-cost savings is a significant low-opportunity-cost saving.

Is there a valid technical reason to use braces?

IMO, the Javascript spec is kinda dumb for being so permissive, but it is covered in the spec, so it's legit to do it either way.

Whether that's a good thing or not.

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

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

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

I'm willing to, please don't withhold enlightenment to spite one guy.

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.

If you aren't careful, you might accidentally write var a, b, c, d, r;

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;

True, and that was part of what I was trying to articulate.

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;

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.

Strict mode should save you from a lot of those.

    (function () {
      'use strict';
      var a = 1; b = 2;
    }());
    // ReferenceError: b is not defined

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.

Reply on news.ycombinator.com