npm’s coding style is a bit unconventional. It is not different for difference’s sake, but rather a carefully crafted style that is designed to reduce visual clutter and make bugs more apparent.
Here’s the example from the npm styleguide regarding comma first:
The array example actually looks visually pleasing, but everything falls apart after that pretty quickly. For one, the stand alone comma at the beginning of a line just makes me cringe. This does not happen in normal language. On the other hand, the array literal in most programming languages is modelled after something that we use in normal language every day, the comma separated list. Add flour, water, sugar, two eggs, stirr quickly.
So, while the CF syntax does have a few technical benefits, what gets completely lost here is the connection of our programming languages to, well, our languages, which doesn’t only make me cringe, which is bad enough, but it also is, by the way our brains are wired by using normal written language every day for most part of our life, way harder to parse. I don’t have real scientific proof for that, of course, only my anecdotal evidence.
Again, a pretty bad violation of normal punctuation rules, but understandable if you hate the visual clutter created by semicolons at the end of statements. Which, I’m sorry, I can’t understand. Yes, I do love me my Ruby, and no, you usually don’t use semicolons there, but then again, we don’t have these funky edge cases to worry about, so unless you don’t want to have more than one statement on one line, your Ruby code will probably never have semicolons in it.
Now, you could argue that the semicolon is a violation of normal punctuation rules anyway, and I love programming languages where a statement is closed by a full stop instead, but somehow someone messed up and now we use the dot to pass messages and the semicolon to end statements. Still, having punctuation at the beginning of a statement looks confusing to me. (The fact that the semicolon is used for one line comments in most LISP variants and Assemblers is only adding insult to injury here)
This all doesn’t invalidate the arguments the author of the npm styleguide. And other people have their own takes on this as well. I also didn’t write all this to diss the npm style and their authors, but to highlight that obviously these people have very different priorities, but also a very different perception about this. The above post by Mikeal Rogers contains this bit:
I’m very happy using the npm coding style and not just for aesthetic reasons. I find that I have less errors and that I can read code faster and tend to lose my place less often than I did before. This is anecdotal and even though I wrote code with semicolons for years you could argue that I had a hidden aesthetic preference for this style I had not yet realized, but you can’t say that this method is error prone because in all this time I’ve never shipped a bug related to lack of semicolon.
To sum up: Mikeal finds npm code more aesthetic and easier to parse. I find, for myself, both to be completely the other way around.
@isaacs spent a lot of time in the comment thread on this gist to again and again explain his rationale. His core argument is that you are getting used to the (un-)aesthetical parts and you end up with only the benefits.
(It is interesting to note that CoffeScript, which I like quite a lot, fixes most of the problems the npm guide tries to address with syntax. The semicolon exceptions are fixed. You don’t need commas in an object literal, so no need to put them in the front, etc.)