5 ms·
Funnily enough, as I've been experimenting with Chef and trying to stick to JSON config files where allowed, I was again struck that (a) it's not a good choice
by robert_tweed 10y ago
Funnily enough, as I've been experimenting with Chef and trying to stick to JSON config files where allowed, I was again struck that (a) it's not a good choice for config files (b) it's an OK choice though (c) lots of people are using it anyway (d) nearly everyone that does so (including Chef) allows comments, so in reality are not actually using JSON at all.
Point (d) is the important one. I really think we need a standard for json-with-comments. JSONC or whatever, but it should have a different standard filename and it should have an RFC dictating what is and isn't allowed. Personally I would allow only // comments because there are too many subtle issues with C-style comments, but it may be too late to agree on that.
Half the point of JSON is that if application A stores its data as JSON then application B can parse that without any nasty surprises. Except, there are now probably thousands of noncompliant implementations in the wild that only exist because the standard doesn't allow comments. Each one of those standards adds subtle differences (in addition to the comments themselves) depending largely on how they remove the comments before passing to the standards-compliant JSON parser (assuming they do that, which being DC's recommended approach, is as close to a standard as currently exists).
- pilif 10y ago> (b) it's an OK choice though I really think it's not an OK choice. A config file format that doesn't allow comments provides some of the worst possible UX. One of the nice things about config files is that normally they are self-documenting, explaining the meaning of the various directives and providing possible values. Without comments, you have to constantly switch between the documentation and the config file. Also, the restriction on trailing commas is another really bad issue for a config file language as it pollutes diffs, makes moving lines around needlessly difficult and is one more landmine waiting to happen for the sysadmin editing a file. No. JSON not at all OK as a config file language.
- mSparks 10y agoHow does json "not support comments"? {"comment":"default values for this object"}
- pilif 10y agoSince when is in-band signalling a good idea? What if one of your configuration keys is named "comment"?
- DonHopkins 10y agoAnd what do you name your second comment?
- mSparks 10y ago{"notes to self":["Don't edit config files by hand","use a decent hierarchy"]} //Http://jsoneditoronline.org
- DonHopkins 10y agoYou could even write comments as a linear RSS feed of nested OPML outlines, by converting all that XML to JSON. http://convertjson.com/xml-to-json.htm http://convertjson.com/xml-to-json.htm
- mSparks 10y agoYep, I went through the process of replacing all our XML objects into json ones about 6 years ago now. Smaller files and much easier to read, manipulate store and transfer. And while I personally quite liked XSLT, javascript is a much more flexible and reliable option.
- inimino 10y agoFor one thing, not every place where you might want a comment happens to be in an object.
- mSparks 10y agoLike where? Who for? For what purpose? I cant think of a single example that this would be useful.
- paulddraper 10y agoDid you miss the part where parent says he is using JSONC?
- protomikron 10y ago> I really think it's not an OK choice. A config file format that doesn't allow comments provides some of the worst possible UX. Are we sure about that? E.g. mostly when messing with configuration files, I have to visit the documentation anyway, which could explain key-value pairs in the json file. Furthermore there are configuration files which consist mostly of comments to explain all kind of edge cases with actual configuration data commented, which can be a mess on its own. If good code should be self-explanatory then why not configurations?
- steveax 10y agoWe have had good luck with HOCON for config files: https://github.com/typesafehub/config/blob/master/HOCON.md https://github.com/typesafehub/config/blob/master/HOCON.md
- DonHopkins 10y agoReflecting the great tradition of "C++", I hereby propose calling it "//JSON".
- deleted 10y ago[deleted]
- erik14th 10y agoI like HJSON[0] for files you need to edit manually. You have comments and other user friendly things. [0]https://hjson.org/ https://hjson.org/
- ocschwar 10y agoJSON with comments? How about { "object":{ "foo":1,"bar":"New Jersey"} , "_comment": "blah blah blah" } A bit hackish, but always worked for me.
- robert_tweed 10y agoNow add a comment for foo and another one for bar. Also try it when your client throws an exception whenever it encounters invalid keys in object. Or if perhaps it blindly persists or tries to perform some logic using that "data". And so on.