6 ms·
> (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.
by 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.
- damncabbage 10y agoA list of items in an array. Some items in that list are of particular note. (Say you have 15 items in an array. For whatever reason, such as you not being in control of the expected input structure of whatever you're giving this JSON to, you have them grouped with comments at the top of each block.)
- mSparks 10y agoWhy would you want to do that in what is basically a human readable binary file and not in a readme? You seemed to stop at the for who and for what purpose. I can 'just' about see the case in something like nodeJS package.json files (that is the least of nodeJS's problems, but that's a whole other conversation). But a readme is a so much better option than having to troll through code comments.
- inimino 10y agoThe discussion above concerns why JSON isn't a good choice for configuration files. That's exactly because configuration files are not human readable binary files.
- mSparks 10y agoTBH. I find package.json files to be much much much much nicer files than configure.sh or settings.txt files, even a configure.py. And if that isn't the case for you, not like you don't have the choice.
- 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?