5 ms·

That example gist went a long way towards convincing me of isaacs' comma prefix style. To me, consistency is important. All of my codebase is traditional comma

• jashkenas 14y ago
  To play at devil's advocate, please don't. Otherwise you should have written your comment like this: To me , consistency is important . All of my codebase is traditional comma postfix , so I'll keep using that ; however , maybe with some new projects I'll try on the comma prefix [...] ... using typography in a typographically sensible way is far more important to readability than an arbitrary "consistency" of punctation. We're humans, not computers, after all.
  • asolove 14y ago
    Why does nobody ever mention the obvious solution? Separate var statements. They're always correct, they copy without any editing, and the "var"s line up to show that it's a block of assignments the same as commas or whitespace.
    • chc 14y ago
      You can only put var at the beginning of variable declarations, but there are many other places that commas are used as a separator. So that "solution" doesn't apply in general.
      • asolove 14y ago
        I think I might have explained myself poorly. I'm suggesting using separate var statements for each assignment, e.g.: var a = 2; var b = 4; var c = { blah: "whatever" }; Leaving out a semicolon has no effect. They can be copied without any fuss. It's easy.
        • ricardobeat 14y ago
          Problems with semi-colons usually arise in object usage. So your solution is very specific. x = {[ { id: 1, data: 0 }, { id: 2, data: 0 } ], [ { id: 3, data: 0 }, { id: 4, data: 0 } ]}
    • slexaxton 14y ago
      Most people also apply this to object literals. There are no var statements in this situation.
    • mnutt 14y ago
      With separate var statements, you never end up with this situation: var foo = 1, bar = 2 baz = 3 In 90% of the cases the code will run the same whether or not there is a comma on line 2, but in the other 10% you will get burned in odd ways now that `baz` is a global variable.
      • Isofarro 14y ago
        JS Lint is your friend in this case. It will log that * There's a missing semicolon on line 2 * There's a missing semicolon on line 3 * baz was being used before it was defined. That's just in a global context. When it's in a function you get a little more: * the baz line is indented too far - because it's being interpreted as a new statement. Sure, you could eyeball your code looking for this. Or just use an automated tool that'd do it for you
    • andywhite37 14y ago
      Separate vars is what I prefer to do, but JSLint actually recommends that you change multiple var statements to a single var with variables separated by commas (and with a semicolon at the end of course!). (And also all var declarations at the top of the function...).
  • rapind 14y ago
    This. I admire code that reads like english. Leading commas are a terrible idea in my humble opinion. It's so ugly to me that the whole idea seems like it could be a troll.
    • UnFleshedOne 14y ago
      I use leading commas in any list that is not one liner in C++. This way the code looks pretty, and that is way more important that code that reads like english. :) (I shudder from dread every time I look at applescript...)
  • slowpoke 14y ago
    And let me play the advocatus Dei , because that actually looks quite readable . Though, more seriously, using English (a natural language) to try to make an appeal to absurdity about the format style of a formal language, is plain absurd.
  • amackera 14y ago
    Even in your example you were consistent, so was I. Inconsistency would be To me, consistency is important . All of my codebase is traditional comma postfix , so I'll keep using that; however , maybe [...] Which is more confusing than either of our consistent examples. Unless I misunderstood your point.
• ynniv 14y ago
  That example gist went a long way towards convincing me of isaacs' comma prefix style. What convinced you? I read it and saw something wildly different, which is best reserved for a good reason. The reason appears to be visual recognition of delimiter mistakes that the parser will catch anyway. The gist contains examples of various mistakes in both styles. Most of the errors are syntax error which will be immediately rejected by a parser. While the comma first errors are generally more obvious, they are silently bad by unexpectedly returning undefined. The standard "var" example is silently bad by leaking vars into the global scope when chaining initializers on a single "var". My conclusion from these samples is that comma prefix formatting only practically helps to prevent hidden mistakes in chained "var"s. Putting each variable declaration on a line of its own is far less distracting than reformatting every list and object. Sample comma first style error. This seems like a strange thing to do, but I'm unfamiliar with this style. return { a : "ape" , b : "bat" } // returns undefined, // then creates a block with two named statements. Sample standard style error: var a = "ape eat banana", b = "bat, allowed to fly", c = "cat toy", d = "dog chasing the mailman," e = "elf lord", .... // leaks "e" into global scope
  • ricardobeat 14y ago
    How about a sample standard-style error: return { a : "ape", b : "bat" } The error here has no relation to the commas.