Revisiting the style guide?

I’m sure this is opening a can of worms but the [style guide] seems a little dated and I’d like to suggest 2 changes

prefer const and let to var?

I don’t know why var is preferred (was told to change to var in a recent PR). My guess is because that’s where it started and because const and let are new. But now that code base is using ES5 modules it seems like any reason for keeping var is long gone. Because of the import lines, for code to work on browsers that only support var the code has to be run through a transpiler. That same transpiler is/will already convert const and let to var.

Further, there are concrete objective positives to using const and let over var. Both are scoped to braces instead of function scope. Neither create global variables unlike var. Sure, much of the code uses var now (although IIRC eslint can auto fix that). Changing the linter to require const and let and slowly changing legacy code over will prevent more errors and leaks. Also with const and let used everywhere it’s possible the enable eslint checking for more undefined variables which at least for me as been a huge help.

There was a time when var was faster but that time is long gone.

Is it time to stop using var?

allow trailing commas in multiline arrays and objects

This might be a personal preference by Mr. Doob but my guess is more that it’s left over from IE days. IE didn’t support a trailing comma but now that transpiling is happening the trailing commas get removed by the transpiler for IE compatibility. For devs trailing commas are a win as they lead to less errors. Errors that are usually caught but errors that often require at least one iteration to catch, running in the browser and seeing the syntax error then going back and editing commas. At least in my experience trailing commas avoid that issue.

By trailing commas in multiline arrays and objects I mean for example

 const sizes = [
     100,
     200,
     300,
 ];

and

 const options = {
    width: 100,
    height: 200,
    depth: 300,
};

With trailing commas adding or removing lines requires only dealing with a single line. With trailing commas it means always having to be aware the last comma is and removing it or adding it.

Of course whatever is decided is fine, I’ll follow the guide for PRs. I just thought I’d ask as the code switched to ES5 modules if it was time to revisit some of the style guide (note the var part is not actually in the style guide.)

Author: Fantashit

6 thoughts on “Revisiting the style guide?

  1. I personally do not vote to allow trailing commas in multiline arrays since I find it unusual to read, too.

  2. For me the purpose of trailing commas is that it makes it quicker to add and remove things, as well as reorder them by cut / paste. No need to worry if you just cut the last item or not, every line is the same. As for seeing undefined, it’s easy to avoid that if you know there’s just one item per line – and in cases where the array is on one line like [1, 2, 3, 4, 5] you would not add a trailing comma.

    On the other hand, I don’t think it matters either way. The switch to const / let is the important issue here.

  3. The trailing commas is one of the best js patterns i’ve seen and makes diffs much more legible.

  4. JS interpreters remove that comma these days?

    All browsers have been fine with that comma in arrays and objects for > 10yrs except IE

    Let me add rather than looking at it as strange thing another POV is that the syntax is actually the comma is required it’s just browser gives you a break and doesn’t require the last one. One person’s strange is another person’s beautify. I find the consistency of every line being the same more personally pleasing than the last line being different. Of course those are personal preferences I’m just bringing them up another way to look at things.

    as for diffs I found these comparisons online

    no trailing comma diff adding a line

    trailing comma diff adding a line

  5. Let me add one more POV for trailing commas 😜 You can see trailing commas as similar to semi-colon

    This is perfectly legal code

     {
          doThis();
          doThat();
          doOther()
     }
    

    The last line missing the semi-colon. One POV is to see comma as the same thing. Maybe it’s like the people/lamp illusion.

    Whether you see 2 people or a lamp stick both are valid. But in that case, with comma since both POVs fit (“comma on end looks like , undefined” vs “comma missing looks inconsistent”) one has objective benefits and the other doesn’t so …?

Comments are closed.