4 ms·

One drawback to JSON files, and XML files and a number of other text file formats as well, is that they allow variable formatting. That makes them difficult to

One drawback to JSON files, and XML files and a number of other text file formats as well, is that they allow variable formatting. That makes them difficult to work with using tools like diff, which takes away a lot of the power of version control. For example, you can take a JSON file and format it two ways: all on one line with little or no whitespace, and pretty-printed with multiple lines and indenting. Semantically, the two files are identical because they'll be parsed into the same data structure when you read it in. Textually they're completely different, which becomes a problem when two people with two different editors that use the two different formats when writing the file try to work on it. If person A commits the file pretty-printed, and person B makes a small change then commits it minimized, how does person A determine what's changed? It's a hassle. XML suffers from this as well, and can be even worse. In some XML DTDs/schemas elements can be reordered without changing the semantic meaning of the document. I've also had this problem with CSS files, which are partially order-dependent. If you have a big CSS file with lots of rules that cover different parts of your site, there are clumps of rules that are related and must be in the right order to cascase properly, but the clumps are mostly independent and their order doesn't matter. In the past I've written tools that canonicallize formats like these just for doing diffs. It's a hassle, but it was necessary to allow my team to manage changes in shared resource files, and it worked well. Today, I'd use a tool like that as a git commit hook so that the repository always contained the format I wanted (assuming it's still usable in that format, which wasn't always the case) but back then I didn't have that option.

scott_s 15y ago
Textually they're completely different, which becomes a problem when two people with two different editors that use the two different formats when writing the file try to work on it. If person A commits the file pretty-printed, and person B makes a small change then commits it minimized, how does person A determine what's changed? It's a hassle. Granted, but the exact same problem exists for most programming languages. I don't bring this up to dismiss your complaints, but to admit I'm surprised you found it to be a problem. While you mention a technical solution at the end of your post, I figured most people handled this with a non-technical solution: agreed upon formatting guidelines.
- DougWebb 15y ago
  My source code editors rarely reformat my code to suit their tastes, unless I explicitly ask for them to do that. Configuration file editors will often reformat the output as they like, because "you're not editing the config file directly anyway". A real-world example I've been dealing with lately are the sln, csproj, and xml files used by Visual Studio. VS is constantly rearranging entries in these files when I modify my projects. Add a dependency to one project, and VS will resort all of the dependency guids for all of the other projects in the solution. When I check my change in, the sln file looks like I've made hundreds of changes (I've got a lot of projects in my solutions) when I've only made one change. Of course, VS shouldn't be doing that. But it's probably not even intentional; I'll bet the VS developers thought "Hey, we should use XML for our sln files because it's textual and readable", and they chose an XML serialization library that was already part of the platform. Then the completely separate group responsible for the XML serialization library probably thought "Hey, when we're serializing this particular type of data structure, let's sort the list elements by something arbitrary, like their memory address", and now your sln file gets re-arranged every time you modify it. This can happen to any xml-based configuration file that doesn't have strict ordering as part of the schema.
  - scott_s 15y ago
    Ah, that's the answer: automated tools are making the changes, not human developers.

scott_s 15y ago

Textually they're completely different, which becomes a problem when two people with two different editors that use the two different formats when writing the file try to work on it. If person A commits the file pretty-printed, and person B makes a small change then commits it minimized, how does person A determine what's changed? It's a hassle. Granted, but the exact same problem exists for most programming languages. I don't bring this up to dismiss your complaints, but to admit I'm surprised you found it to be a problem. While you mention a technical solution at the end of your post, I figured most people handled this with a non-technical solution: agreed upon formatting guidelines.

DougWebb 15y ago
My source code editors rarely reformat my code to suit their tastes, unless I explicitly ask for them to do that. Configuration file editors will often reformat the output as they like, because "you're not editing the config file directly anyway". A real-world example I've been dealing with lately are the sln, csproj, and xml files used by Visual Studio. VS is constantly rearranging entries in these files when I modify my projects. Add a dependency to one project, and VS will resort all of the dependency guids for all of the other projects in the solution. When I check my change in, the sln file looks like I've made hundreds of changes (I've got a lot of projects in my solutions) when I've only made one change. Of course, VS shouldn't be doing that. But it's probably not even intentional; I'll bet the VS developers thought "Hey, we should use XML for our sln files because it's textual and readable", and they chose an XML serialization library that was already part of the platform. Then the completely separate group responsible for the XML serialization library probably thought "Hey, when we're serializing this particular type of data structure, let's sort the list elements by something arbitrary, like their memory address", and now your sln file gets re-arranged every time you modify it. This can happen to any xml-based configuration file that doesn't have strict ordering as part of the schema.
- scott_s 15y ago
  Ah, that's the answer: automated tools are making the changes, not human developers.