-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Diff friendly literals #80
Comments
I patched up the Firefox JSONView extension a while ago to employ this layout (xpi at http://ecmanaut.blogspot.com/2010/09/jsonview-with-copy-paste-support.html for the curious), as it's also very copy-paste friendly (you can easily double click to select lines, and see that you copy everything on the same "comma indentation level" in effect), and that's where I grabbed the above example literal (I just filtered out the spammier parts; sorry about that). |
I love this style. +1. |
That's intense bending backwards to endure the imperfections of the tools That said
|
I'm not saying it's the one thing it's got going for it, but it's the first one I came up with, trying to find its raison d'être. Like anything with syntactic code style it's a matter of taste and preference, and I now find this way easier both to read, write and work with in general, having used it a couple of months at most. I think it's various aspects of your third point that add the most. I never tried applying it to English, but your example surprisingly gained clarity from it, despite probably intending to mark its ridiculous looks. :-) As suggested in my post above, I had a caustic reaction to this thing too initially, but decided to prove myself right or wrong about it empirically by using it for a bit, and I am not looking back about it. |
Might be of interest: One sentence per line, please |
Please take a look at branch Tell me if this is a sufficient first step towards what you want that I should add it to the next release. |
I'd like a "diff friendly literals" indentation style that puts element separator commas and leading
{
or[
characters at the beginning of the line instead of at the end of it, and]
and}
characters on a line of their own.I first encountered this indentation style for literals (and function calls with lots of arguments spread across multiple lines):
It looked weird and broken enough for me to ponder why I reacted strongly to it and why anyone would possibly prefer it, and it immediately dawned on me: because it solves an even more annoying problem:
In line-based version control systems (read: all of them), whenever you add or remove a property in a chunk of JSON, the diff touches not just the lines of the new properties you added, but also changes the line before it which now gets another comma character in place of the
]
or}
that was there before, which leads to uglier changesets.The above indentation style doesn't have that problem (except in the rare case when an empty object or array becomes not so, and vice versa), as each new item comes with its own comma, on its own line.
The text was updated successfully, but these errors were encountered: