-
Star
(259)
You must be signed in to star a gist -
Fork
(34)
You must be signed in to fork a gist
-
-
Save isaacs/357981 to your computer and use it in GitHub Desktop.
// See comments below. | |
// This code sample and justification brought to you by | |
// Isaac Z. Schlueter, aka isaacs | |
// standard style | |
var a = "ape", | |
b = "bat", | |
c = "cat", | |
d = "dog", | |
e = "elf", | |
f = "fly", | |
g = "gnu", | |
h = "hat", | |
i = "ibu"; | |
// comma-first style | |
var a = "ape" | |
, b = "bat" | |
, c = "cat" | |
, d = "dog" | |
, e = "elf" | |
, f = "fly" | |
, g = "gnu" | |
, h = "hat" | |
, i = "ibu" | |
; | |
// 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" | |
; | |
// Objects: | |
// JSON.stringify style | |
var o = { | |
a : "ape", | |
b : "bat", | |
c : "cat", | |
d : "dog", | |
e : "elf", | |
f : "fly", | |
g : "gnu", | |
h : "hat", | |
i : "ibu" | |
}, | |
a = [ | |
[ "ape", "bat" ], | |
[ "cat", "dog" ], | |
[ "elf", "fly" ], | |
[ "gnu", "hat" ], | |
[ "ibu" ] | |
]; | |
// comma-first | |
var o = | |
{ a : "ape" | |
, b : "bat" | |
, c : "cat" | |
, d : "dog" | |
, e : "elf" | |
, f : "fly" | |
, g : "gnu" | |
, h : "hat" | |
, i : "ibu" | |
} | |
, a = | |
[ [ "ape", "bat" ] | |
, [ "cat", "dog" ] | |
, [ "elf", "fly" ] | |
, [ "gnu", "hat" ] | |
, [ "ibu" ] | |
]; | |
// errors in objects: | |
// JSON.stringify style | |
var o = { | |
a : "ape", | |
b : "bat", | |
c : "cat", | |
d : "dog" | |
e : "elf", | |
f : "fly", | |
g : "gnu", | |
h : "hat", | |
i : "ibu" | |
}, | |
a = [ | |
[ "ape", "bat" ], | |
[ "cat", "dog" ], | |
[ "elf", "fly" ] | |
[ "gnu", "hat" ], | |
[ "ibu" ] | |
]; | |
// comma-first | |
var o = | |
{ a : "ape" | |
, b : "bat" | |
, c : "cat" | |
, d : "dog" | |
e : "elf" | |
, f : "fly" | |
, g : "gnu" | |
, h : "hat" | |
, i : "ibu" | |
} | |
, a = | |
[ [ "ape", "bat" ] | |
, [ "cat", "dog" ] | |
, [ "elf", "fly" ] | |
[ "gnu", "hat" ] | |
, [ "ibu" ] | |
]; | |
// Addendum: effects on the return statement. | |
// It does not break. | |
return [ 1 | |
, 2 | |
, 3 | |
] // returns [1,2,3] | |
return { a : "ape" | |
, b : "bat" | |
} // returns {a:"ape",b:"bat"} | |
// even just separating two values by commas is fine, | |
// though a bit silly | |
return 1 | |
, 2 | |
, 3 | |
, 4 // returns the last value, 4 | |
// this, however is wrong: | |
return | |
1 | |
, 2 // returns undefined, because of semicolon-insertion. | |
// so is this. otb == fail. | |
return | |
{ a : "ape" | |
, b : "bat" | |
} // returns undefined, | |
// then creates a block with two named statements. | |
// this is ok: | |
return ( 1 | |
, 2 | |
) // returns 2 | |
// so is this: | |
return ( | |
{ a : "ape" | |
, b : "bat" | |
} | |
) // returns {a:"ape",b:"bat"} | |
// Addendum 2: A function call | |
doSomething( aPrettyLongVariableName | |
, "A string, which has some useful information" | |
, "If you put these all together, it'd be too long" | |
, { a: "is for antelope", b: "is for bat" } | |
, 42 | |
) | |
// Addendum 3: More realistic error in standard style: | |
// leaks FIVE globals! | |
var a = "ape eat banana", | |
b = "bat, allowed to fly", | |
c = "cat toy", | |
d = "dog chasing the mailman," | |
e = "elf lord", | |
f = "fly through the air", | |
g = "gnu is not unix", | |
h = "hat goes on your head", | |
i = "ibu isn't a cow"; | |
// Error: Can't call method 'forEach' of undefined. | |
// not passing in undefined as an argument!?? | |
mergeLists([ apple, [ penelope, granger ] ], | |
[ fun ], | |
[ 1, 2, 3, 4, 5, 6, 7, 8 ] | |
[ "mary's store has many pies, and cookies, and eggs," ] | |
[ function() { doSomething() } ]); |
I'm actually a fan of comma first because of the arguments presented above but it indirectly violates google style guidelines.
- https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml#Code_formatting
Binary and Ternary Operators
Always put the operator on the preceding line. Otherwise, line breaks and indentation follow the same rules as in other Google style guides. - http://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s4.5.1-line-wrapping-where-to-break
Where to break
A comma (,) stays attached to the token that precedes it.
@waynebloss thanks for that link. Interesting read.
If you use it first, youre VERY wrong
Dont do it plz.
While I understand the comma-first approach may make JSON-related errors easier to catch, it is by far the ugliest coding convention I have seen in my limited programming career. A good editor usually catches errors related to missing commas in JSON files anyway. I truly see little value in this.
It actually looks much nicer to me this way:
- Var statements line up much more nicely
- Added benefit of catching errors
- You can insert/remove single lines
I always found the comma at the end the most moronic, especially if you append to arrays instead of just inserting at the beginning all the time. You have to add a comma to the previous line, which is inconvenient at best, and problematic at worst.
With the comma before approach, you only have to deal with this issue once (making sure your first definition lines up), and then you're done.
The only disadvantage I see is that there are a lot of formats doing this the old, broken way of 'comma after', including, incidentally, JSON.stringify. Which is why I found this debate at all.
Hmm... 'use strict' prevents leaking to global. When I add to var blocks (which I use infrequently as a means of being articulate), I do so to the middle more so than I do to the beginning and end. But if I encountered this code from someone else, I don't think I'd have a 'conventional problem' with understanding it. It looks like a config file that uses commas in a somewhat non-english manor. I don't think I'd like to implement commas in this way though.
Yay! Another pointless code debate.
I can't believe people are seriously debating this and trying to use "arguments" on this topic. It makes about as much sense to debate if a painter should hold a brush in their left or right hand.
It doesn't matter
To left-handed people one answer seems more fitting while right-handed people will opt for the opposite for exactly the same reason.
Just like tabs vs. spaces, brace placement and first vs. third person narration it all boils down to personal preference.
@isaacs made an effort to explain why this particular style works for him. Well done.
Anyone who considers the title "A better coding convention ..." anything other than click-bait has a lot of growing up to do.
Really... Can we all just go back to debating which Doctor Who is better?
Tip: Beautify && Comma first, Almost No Code!
var obj = {url:"http://example.com",number:1,complex:["first",{second:"null"}]}
- Beautify, comma-last
JSON.stringify(obj, null, 2) { "url": "http://example.com", "number": 1, "complex": [ "first", { "second": "null" } ] }
- Beautify, comma-first - column start ("Greek style")
JSON.stringify(obj, null, 2).replace(/,\n /g, "\n ,") { "url": "http://example.com" , "number": 1 , "objects": [ "first" , { "second": "null" } ] }
- Beautify, comma-first - word start ("English style") - Preferred.
JSON.stringify(obj, null, 2).replace(/,\n /g, "\n ,").replace(/ *(,(\ +))/g,"$2,") { "url": "http://example.com" ,"number": 1 ,"objects": [ "first" ,{ "second": "null" } ] }
Yoda commas.
For nearly 16 years of our lives, we write essay after essay using commas. On top of that, we write billions of emails. With all the variables and preferences in our shared environments, shouldn't we at least adhere to our life-long habit of left-to-right comma interpretation?
In my humble opinion, I prefer reading code that isn't totally opposite our natural tendencies.
This doesn't feel natural at all, although technically it is the same text:
For nearly 16 years of our lives
, we write essay after essay using commas. On top of that
, we write billions of emails. With all the variables and preferences in our shared environments
, shouldn't we at least adhere to our life-long habit of left-to-right comma interpretation?
@NoelBaron, linguistically, a compound-sentence has a comma so you'll pretty much know when to halt for a breather, but on your sample text, inserting a line-break before the comma (creating a comma-first look) also implies a full-stop or a new paragraph, comma on code has no linguistics value, and one should not be looking for such. On inventing a new program-language, we might as well use pipeline, hash-tag or any other characters to separate code-blocks, which do not have analogous meaning in English language-composition thus, not creating this confusion.
Most of pro-comma-first developers usually mention their lack of forgotten commas at the end of a long line of code, or even the OCD relief of same-column-straightening of characters ;)
Anyway, the comma-first convention is gaining quite a lot of popularity among users lately,
I can say that software-developers at Google (Israel) are using it on most of the new projects, due to its superb readability.
I give a star here since I discovered this place lol.
I'm using commas-first style almost since I started JS around 6 years ago now.
Guys you also missed something, commas-first is essential when you use multilines keyboard shortcut.
In VS or Sublime, CTRL + D for few entry in a JSON then END then add somehting, paste, or select a value. You don't have to deal wth the comma at the end.
Also CTRL + SHIT + TOP or DOWN in VS will make a multi-line cursor, then SHIFT + END and you selected all values excepted commas (or just select the keys, or the values, whatever).
I use this everyday everytime and each times I show this to a developer that is not using these shortcuts (and not using commas-first) he reconsider his position lol.
As a general rule, you should split your statement at the highest place possible in your syntax tree. Usually at an operator.
Since that operator is the pivot between 2 lines, it should be put prominently at the begin of the line.
Therefore the comma, or any other operator, +, &&, should start the line.
Use ternjs / eslint and get a life.
Putting the least important characters of the code up front is ridiculous.
actually, I love it and have been using it for years.
the comma on the left just looks like a bullet list.
ever since I stared using it - I never forgot a comma or struggled with braces again, even when working with nano on remote files.
but - I'm working with a team now that will agree to this style only if it will be supported by the lindter.
so - is there an eslint rule I can use to enforce this style, especially for arrays and objects?
Is there an eslint rule that will not choke when you do something like this? My eslint configuration complains about Project
being indented by 2 chars.
const {
Project
, Dimension
, Task
, View
, Layout
, User
, Group
, Organization
, CustomField
} = db.model;
It's too bad so few people use comma (and operator) first.
There are so many bad examples here.
Comma and operator first is really useful when you nest complex data structures or code.
Here is a case where it is good at:
x = {
a : ( b + 27 * (
foo1(
b
+ ( (c + 232312)
* ( foo2(
(d + 3423423 * foo34(34))
* (y+3243)
)
+ foo3(
(234 * sdf + 23 * dfdse )
, 23423 + foo45(23)
)
)
* ( 23423 / 34)
)
+ ( 234234 / sdf + 23423)
+ ( foo4(234234)
/ foo5(
foo34(
( ( fo345(3434 + 2323423)
+ 23423
)
/ 234
)
, [ 23234, 23432, 234234]
)
/ 349
)
)
)
))
, b : 234
, c : [
34534
, 534634
, 98
]
, d : {
x1 : [
23423
, 232
, 43+343*(
343
+ 324
)
, 23
]
, x2: 234
, x3: foo(2323 + (
( foo56(234) + 3434)
/ (2342 + foo6(2323))
))
, x4: 34534
}
}
I don't know how I got there, probably about the trailing comma debate I had with a colleague, but honestly this hurts my eyes so much. You don't do comma-first because firstly it's ugly and unintuitive. Javascript was designed like any coding language to be human-friendly. The creators knew how to read and write english, meaning that you should respect the comma position as you would in an non programming language.
Now if you write like this ,you'll see that this is by far the dumbest way to say "Hey I'm a hipster I write code with comma first" ,that's not how you're supposed to do things and you'll be the only one to do this in a team that would dare to hire you.
Comma is not a operator so I don't see the point how saying it should be the first thing in a line and in english (or any other language), a comma is attached to the previous word and a space (or a new line) must be put after this comma.
I really think I'm in the flat earth conference.
Not a chance @bhubr, some of us like our "comma-style":[2,"first"]
rule ;)
The only place I've seen it cause issues is with JSDOC blocks not being identified correctly by the IDE.
A lot of the examples in this thread are using variables values of same/same character lengths. When line length is random it becomes much more obvious that comma-first adds value.
So far I've not seen a single sound argument here pro comma last. All mentioned here is just comma-first is ugly or stupid.
Those in favour of comma-first mentioned some clear advantages though.
I code comma-first as well, looking for pro comma last, as it seems lots of tools and big names favour comma last. Any objective pro comma-last arguments that I might consider?
English and code are two different things. You cannot justify coding style with English text conventions.
Or we should write in paragraphs, indent the first line, capitalize the first word and justify the rest left and right.
X = {a : (b + 27 * (foo1(b + ((c + 232312) * (foo2 ((d +
3423423 * foo34 (34)) * (y+3243)) + foo3 ((234 * sdf + 23 *
dfdse), 23423 + foo45 (23))) * (23423 / 34)) + (234234 / sdf
+ 23423) + (foo4 (234234) / foo5 (foo34 (((fo345 (3434 +
2323423) + 23423) / 234), [23234, 23432, 234234]) /
349))))), b : 234, c : [34534, 534634, 98 ], d : {x1 :
[23423, 232, 43+343*(343 + 324), 23 ], x2 : 234, x3 : foo
(2323 + ((foo56(234) + 3434) / (2342 + foo6(2323)))), x4 :
34534}}.
And end with a period.
Gosh are people still having this debate in 2024??!? 😆😆😆
People, look around you, the whole industry is using Prettier and nobody cares about this nonsense. It's not 2010 anymore
@happyteque actually surprisingly its still relevant, no matter which language you use.I don't code in JS much anymore, but it's honestly sad this style isn't more prevalent, for one reason: git commits.
Commas are just noise - if you add a line, they are the reason you have two lines changed, not one, or you have random lines added in the middle of your array.
As for reading code, you can go screw your eyeballs and your dipshit opinions both - nobody reads code anymore, and it barely makes a difference. You are just an intolerant twat if you can't stand the difference. Grow the f* up. Everyone else did.
If "growing up" involves insulting strangers on the internets over something as petty as this, no, i'd rather not
Everything alright bro?
@happyteque Nah that part wasn't directed at you.
There are some individuals from ~2019 I'm more responding too, that seem to have had some pretty trash opinions.
"Growing up" means accepting that, normally, this stuff isn't important. And caring about objective stuff, not trash like your arrays looking you want them to.
"So if you want a single reason why not to use this crap, here it is: no one in his right mind does it, and no one wants to hear your explanation about why it's so brilliant,"
Touche. Maybe you should follow your own advice, lol.
So far I've not seen a single sound argument here pro comma last
@KoJaMan Lack of reading comprehension and/or willful ignorance does not an argument make.
The only comment you really need to read about this is mine, right here.
Good day.
Whoever said "use better tools" was right. (And there is a wrong here.) Comma-first style seems analogous to burning down your barn to get rid of some rats. Don't do that! Just get some rat traps.
Of course you're welcome to "optimize for [your] human brain", but don't think that you're optimizing it for other people's brains (or even the majority). If you just use tools to catch these mistakes, you can avoid the whole issue.
This guy is right too - you want punctuation to disappear when you're reading code - http://blog.outsharked.com/2012/05/on-javascript-style.html