4 ms·
Tools that use JSON as configuration format could simply allow certain unused keys (e.g. all keys starting with #) and promise never to use them. Then author ca
by runarberg 5y ago
Tools that use JSON as configuration format could simply allow certain unused keys (e.g. all keys starting with #) and promise never to use them. Then author can write their comments with something like:
{
"name": "my-tool",
"#comment-1": "Don’t change the version!",
"version": "42.1337.0"
}
- posharma 5y agoI've heard and read this multiple times. Why are you trying so hard to fit into a format that doesn't just support comments out of the box? What advantages is JSON offering you that you've compelled to bend over backwards to do this? It's exactly these kinds of workarounds that is making it super difficult stop such malpractices. It's just plain ugly. Please stop doing this.
- cbm-vic-20 5y agoIn many cases, you're using a library or service that you don't maintain, so you don't have much of a choice.
- justinpombrio 5y agoThere's a lot of JSON tooling, and it's liable to interact badly with this. For example, a formatter might re-order the fields of a dict, moving "#comment-1" away from "version". Or the software that this JSON is for might error upon receiving unexpected keys (which is actually useful behavior, as that would catch a typo in an optional field). Also, this doesn't let you put comments at the top of the file, or before a list item, or at the end of a line. If you're going to change your JSON tooling to handle comments of some kind, you might as well go all the way to JSONC.
- argomo 5y agoYou can't comment out a large section of config easily. For me, this is a relatively common use case for config files, so I take the position that JSON should be used for serialization only.