Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was afraid to read the style guide for fear of seeing the preceding comma pattern (I think it's popular in Node because ryah uses it). Thankfully it recommends the trailing comma :)

    var variable, // trailing comma
        anotherVariable,
        thirdVariable;

    var variable 
      , anotherVariable // preceding comma
      , thirdVariable;


Here's an article about why preceding comma is very convenient:

http://ajaxian.com/archives/is-there-something-to-the-crazy-...

More specifically, in which is it easier for you to find the error?

  // error in standard style
  var a = "ape",
    b = "bat",
    c = "cat",
    d = "dog"
    e = "elf",
    f = "fly",
    g = "gnu",
    h = "hat",
    i = "ibu";

  // error in comma-first style
  var a = "ape"
    , b = "bat"
    , c = "cat"
    , d = "dog"
    e = "elf"
    , f = "fly"
    , g = "gnu"
    , h = "hat"
    , i = "ibu"
    ;


Yeah, I understand why, particularly when old IE browsers don't allow a comma trailing the final declaration. I just find it ugly as hell.


Unfortunately trailing commas still break IE7, which I wouldn't yet classify as old enough to ignore.


I'm not ignoring it but my code always runs through JSLint each time its saved and that picks up misplaced commas for me. Also we're not talking about client-side javascript here; fortunately Node.js uses the V8 Javascript engine, not the IE7 one. :)


I'd rather occasionally have comma bugs than make all my code horrendously ugly. Also, most people don't set their tabstop to 2 characters, which means you have to use space key twice in every variable declaration. That's got to be annoying.


Many node projects use soft tabs set to two spaces.


If that's so, why do we not see this in other mainstream languages? While I see the slight advantage of seeing errors, that is the first thing node sees. I use either nodemon or cluster, which both monitor your program on saving your code. When you think you're ready to go, save and see if it has no compile errors.


I don't know if haskell counts as a mainstream language, but it's pretty common to see this pattern in a module's export list. I go back and forth.


Haskell's an odd case; experienced Haskell users are likely to be thinking of the comma as less of a "separator" than a "combinator" constructing a tuple, and preceding-combinator-on-newline is an idiomatic style. Which doesn't disprove your point, I'm just saying it's an edge case. This is after all the language community that interprets a semicolon (as used in most languages) as a combinator too.


I do this all the time on large SQL statements. Otherwise, I rarely use the comma operator, so it hasn't come up.


I was afraid to read the style guide for fear of seeing K&R vs Allman indents/braces. As usual, it was hit on. However, to my amusement, the "Right" way of doing things actually has a syntax error:

  if (true) {
    console.log('winning);
  }


I have been personally screamed at for suggesting One True Brace Style over K&R in response to a request for feedback on an architecture standards document. That was when I learned that corporate architecture teams don't actually want to get feedback when they ask for it.

I find it odd that I have a strong opinion on the topic but have never seen a convincing argument that one way is actually better than another, it's just that one feels right to me and the others don't and I can't articulate but neither can anyone else I've seen.


I don't know about other languages but there are real practical reasons to choose 1TBS in Javascript, consider the following code:

    return {
        key: 'value',
        anotherKey: 'another value'
    }
This is fine and works as expected, now consider the following K&R/Allman style code...

    return
    {
        key: 'value',
        anotherKey: 'another value'
    }
In Javascript this is parsed as `return;` (notice the semi-colon), this is because Javascript does its dreaded automatic semicolon insertion magic.

So, I think that's a pretty good practical reason to prefer 1TBS in Javascript.


I favour a mix of the two in javascript - 1TBS for object literals and anonymous functions, K&R for conditionals and named functions.


Thank you! I didn't actually know this and would have completely missed that bug.


Fixed. Sorry, I was typing most of this on my iPad.


Other than style, is there an advantage to either of them over just declaring each one separately?

  var variable;
  var anotherVariable;
  var thirdVariable;
One issue I see with multiple variable declarations is that a forgotten comma doesn't cause a syntax error, it just causes that variable and any after it to be global variables. Which leads to much nastier javascript bugs.


For Node code, not really. For browser code, usually not really, but for high traffic sites or widely used libraries every character counts.


Y'know, I apparently haven't been plugged in enough to JS to realize that as a valid solution, because Python has spoiled me letting me terminate tuples with a comma (which I find elegant and painless) -- but the preceding comma pattern at least makes it easier to troubleshoot code and doesn't make me feel TOO much like I'm just trying to avoid pissing the interpreter off.


You can do that in Node.js too, just not in MSIE <= 7.


I hate the comma in variable declarations personally I use a new 'var' keyword on every line.


Does the preceding comma style not get in the way of JavaScript's auto semi-colon insertion?


It appears it doesn't, but I'd like to know WHY it doesn't.

Do Javascript parsers look at the next line before judging whether or not to treat the line-ending as an implicit semicolon?

(Do all parsers treat it in the same way? Is it part of the spec?)


Everything you need to know:

http://blog.izs.me/post/2353458699/an-open-letter-to-javascr...


Yes. Yes. Yes.


I use the comma-first style in everything (in languages that have this problem) now that I know about it. I was also interested to see it with semicolons in Simon PJ's chapter in Beautiful Code.

I just wish the character was something other than a comma! It looks so wrong in that position.

BTW, your second example should be

    var variable
      , anotherVariable // preceding comma
      , thirdVariable
      ;
Perl and Python don't have the trailing-comma problem in most contexts, but they do have a similar problem with some other infix operators. For example, I'm still not sure whether I should use it for strings:

    var myString = "This string is a bit too long to fit "
                 + "comfortably on a single line, so I "
                 + "have split it across three lines."
                 ;
The problem with this is that the first line looks like a standalone JS statement. Python requires you to wrap the whole thing in parens, which solves that problem:

    readMyString = ( "This string is a bit too long to fit "
                   + "comfortably on a single line, so I "
                   + "have split it across three lines."
                   );
The other language besides JavaScript where I find it useful is SQL:

    create table text_editors ( name varchar
                              , latest_version varchar
                              , list_of_stupid_flaws blob
                              );
I suspect that this approach would fix most of Damien Katz's complaints about Erlang's syntax in http://damienkatz.net/2008/03/what_sucks_abou.html:

Because Erlang's expression terminators vary by context, editing code is much harder than conventional languages. Refactoring -- cutting and pasting and moving code around -- is particularly hard to do without creating a bunch of syntax errors.

His example:

    blah(true) ->
      foo(),
      bar();
    blah(false) ->
      baz().
becomes

    blah(true) 
      -> foo()
       , bar()
       ;
    blah(false) 
      -> baz()
       .
His example transformation of reordering the branches now works correctly simply by cutting and pasting lines, albeit in two chunks (just as it would be in JS), and moreover any error in the process is visually obvious:

    blah(false) 
      -> baz()
       ;
    blah(true) 
      -> foo()
       , bar()
       .
His other transformation, of changing the order of foo() and bar(), still isn't trivial, but it's still visually obvious when you screw it up:

    blah(true) 
       , bar()
      -> foo()
       .


In the specific case of Python string concatenation, you don't need the operator at all:

  >>> x = ( "abc"
  ...       "def" )
  >>> x
  'abcdef'
Erlang also works this way. Note it only works for string literals.

But that's just FYI, it obviously doesn't affect your point.

It's actually slightly strange to me that for everything else Perl does that this doesn't work in Perl.


Oh, thanks! I'd forgotten that C feature of Python. Unfortunately it doesn't work in JS.


The case of Erlang is more or less a matter of preference. I haven't seen any piece of Erlang code with the separator first, except in the case of the if expression:

  if Cond1 -> Exp1
   ; Cond2 -> Exp2
   ; ...   -> ...
   ; CondN -> ExpN
  end
Other than that, meh. I think Erlang just needs to read/write code differently. My blog post on the issue: http://ferd.ca/on-erlang-s-syntax.html


The problem with this is that the first line looks like a standalone JS statement. Python requires you to wrap the whole thing in parens, which solves that problem:

Well, doesn't JS allow you to wrap it in parens if you want?


Why do ryah et al do it?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: