Introduction
Comma-leading lists are an objectively better presentation style.
They make logical sense; the next value on the list is dependant on the comma, and so, they should be kept together.
The style may look alien at first, but give it a test drive and you'll be surprised at how quickly it starts to look normal.
For now, let's have a look at the benefits.
Justification
1. No Merge Conflicts
When adding a new value to a list with trailing commas, you're making 2 additions and 1 deletion.
This will give you a merge conflict just because someone else adds a value on a different branch.
By using the comma-leading style, you make 1 addition and 0 deletions.
These commits play ball with each other, without needing any conflict resolution.
"Ah, but I've used a dangling comma," you say? Allow me to continue.
2. Dangling Commas Bad
It's true that using a trailing comma after the final value will prevent conflicts, but it's dumb for two reasons.
1. Language Inconsistency
SQL doesn't support them.
The JSON standard and Pre-ES5 JavaScript don't support them.
It's better to stick to a style that works across more languages, especially for a multi-lingual codebase.
2. Redundant Logic
There's not a second element. It's unnecessary context, so why justify it?
And, if an interpreter ever decides to stick a None in there, good luck.
3. Better Presentation
Separating Context
With the comma-leading style, the logic stays on the left, and the data stays on the right.
This makes it quicker and easier to scan when looking through code.
It will also allow you to quickly identify logic errors, such as missing commas.
Saving Whitespace
When you indent after the opening bracket, you're adding extra columns of whitespace on the left-hand side.
Placing the commas on the left keeps the code neat and narrow. Neat!
Summary
Comma-leading lists are easier for source control, more compatible across languages, and much faster to read since they keep data separate from the list's logic.
Do the world a favour and switch to a better standard of data structure.
animals = [ "ant"
, "bat"
, "cat"
, "dog"
]
What's not to love? 😉
Hey, guys! Thank you for reading. I hope that you enjoyed this.
Keep up to date with me:
- DEV: https://dev.to/tao/
- Twitter: https://twitter.com/LloydTao
- GitHub: https://github.com/LloydTao
- LinkedIn: https://www.linkedin.com/in/LloydTao/
Catch you around!
Top comments (24)
Admit it, you just wanted to make people mad
I read it, I saw maybe a thin benefit. But I just can't do it. It make me want to cry.
I do similar for ternary and logic operators. It has all the benefits of the above, plus you can comment out the line without having to faff about with commenting the '&&' or '||' at the end of the previous line.
My god this actually convinced me
I write SQL this way - in a SQL editor (like SQL Tools) and in my code (mostly Visual Studio). You can comment out individual items from your select and not break anything if you structure it right.
I didn't read the post so if that's what he said then I completely agree :-)
I refuse to do this. Even though I really should
The git argument seems correct but doesn't it just reverse the problem? Wouldn't adding a value to the top of the list have all the same problems?
adding to the top will create a [+2, -1] diff in both styles. you'll need to keep the opening bracket on its own line to avoid that.
So yes?
uh, yes, but 'reverse the problem' is incorrect since it exists for both
But that depends on the style of the language or developers involved. When having the bracket on a separate line is expected, "reverse the problem" seems correct to me.
separating the bracket will fix the problem for both styles.
logically speaking, there’s no ‘reversal’ no matter how you peg it, as you’re coupling the data with its dependent comma instead of separating them
The reversal is in the location of where the style causes potential git merge issues. With comma-first the issue can happen at the top of the list with comma-last the issue can happen at the bottom of the list.
Im not sure what you mean by removing the dependency on the comma. If the language uses commas to separate the data there is no real way to remove that dependency. It is built into the language.
ah, i get you, so in the case where brackets are on their own lines, prepending the list will still cause a double diff
in fairness, i’d argue that appending is much more common from my personal experience, be it adding adding data to a JSON, extending an SQL query or passing more attributes to an HTML tag
good spot, though 🙂
I wonder the probability of encountering such a merge conflict versus the amount of code you will write (and read) in a not-so-human-readable way. The complexity introduced doesn't justify its use case.
This is genius!
In Elm this is the norm ❤️
I hadn't encountered comma first until recently in some old code. Drove me crazy and I couldn't figure out why someone would do that. This explanation makes a lot of sense.