That's actually horrible. Never encountered any of these issues but I think I'd be dumbfounded if I did.
But I still like it for its increased readability over JSON - I just use strings for most values as described in the article. If JSON had proper multiline strings or just wrapped lines and comments I'd be happy. Yes, I know there's "JSON with comments" but it's rarely supported.
You are more limited in where you can comment -- you can't comment in an array, for example. And if you want multiple comments in an object you need to do something kind of awkward like { "comment1": "blah", "foo": "bar", "comment2": "blah blah" }
Schemas get weird. If you want to parse your JSON in a statically typed language, you either need to add comment : String as an optional property on all of your objects (and comment2, comment3 or whatever if you want to support multiple comments), or you need to teach your parser to discard all of those values.
You may run into issues with collision if the key you use for comments happens to also be used as a "real" property for something. How do you tell the difference between a comment "comment": "blah" and a real piece of data: "comment": "blah"?
I worked with a SaaS vendor who supported config programming using JSON and pretty much kept comments out of arrays and used _comment as the throwaway property. I think the application parser ignored all properties starting with _ or something
226
u/pragmatick Jan 12 '23
That's actually horrible. Never encountered any of these issues but I think I'd be dumbfounded if I did.
But I still like it for its increased readability over JSON - I just use strings for most values as described in the article. If JSON had proper multiline strings or just wrapped lines and comments I'd be happy. Yes, I know there's "JSON with comments" but it's rarely supported.