3 ms·

Still don't get the hang up about comments with JSON. I'd find it strange to encounter a config file with lots of internal documentation. They should be small w

Still don't get the hang up about comments with JSON. I'd find it strange to encounter a config file with lots of internal documentation. They should be small with well named, descriptive settings. These are config files. A comment is something that gets ignored, this "comment" will be ignored by whatever ingests this JSON. If not, there are other problems. If you have to write a treatise here, there are other problems. { "comment": "This is a comment", "dev": { ... }, "stage": { ... }, "prod": { ... } } Oh no, that line doesn't start with a # or //, whatever will we do!

karlicoss 7y ago
- sometimes the schema is strict (and you might not be able to control it) - you might not be certain if you break something with such a comment (i.e. you have to double check that all the "comment" fields are filtered) - you're not geting highlighting from your text editor, it's easier to miss a comment - you can't have a comment for a list item Basically, you can leave the comments, but you're really discouraged to do so. Most people would just give up and not bother.
- worble 7y ago
  I think the real loss here is that with a # or // the person reading the file immediately knows this is a comment. This line won't be read by the interpretor, and it's purely here for me to read it, so I probably should do. The following however { "comment": "Some comment", ... } Suddenly I'm not sure if this is meant for me, or if it's actually a configurable state without going into the program itself and checking if it uses it.
  - Ididntdothis 7y ago
    Putting a comment into the payload is just a terrible hack. this shouldn't be necessary,
Ididntdothis 7y ago
Your "comment" is part of the data so it's not a real comment. I don't understand the resistance against adding comments to JOSN. This seems pretty silly to me.
u801e 7y ago
> Still don't get the hang up about comments with JSON. I'd find it strange to encounter a config file with lots of internal documentation. A lot of mainstream applications come with documentation in the sample config file that explains what each setting does and what its default value is. For example, this is the default configuration for redis[1]. Having that information in the config file guides users in terms of what's possible to change and what values can be used. [1] https://raw.githubusercontent.com/antirez/redis/5.0/redis.conf https://raw.githubusercontent.com/antirez/redis/5.0/redis.co...
wenc 7y ago
Commenting in complex configs is actually a highly compressed signal for communicating a lot of information without a lot of unwieldy external documentation. INI files support comments. apache.conf or any number of Linux config file support comments. Also, executable configurations are not uncommon. Consider .bashrc or .vimrc. And they're usually loaded with multi-line comments. Embedding comments in JSON fields gets unwieldy really quick for long configs. Compare: { "generalcomment": "the quick brown fox\njumps over the lazy dog", "setting1" : {}, "setting1comment" : "this is setting1", "setting2tree": { "setting2a": {}, "setting2acomment: "this is supposed to do this", "setting2b": {}, "setting2bcomment: "this is supposed to do this" }, "setting3": [1,2,3] "setting3comment": "to use this setting, do this" } To: // The quick brown fox // jumps over the lazy dog. { "setting1" : {}, // this is setting1 "setting2tree": { "setting2a": {}, // this is supposed to do this "setting2b": {}, // this is supposed to do this }, "setting3": [1,2,3] // to use this setting, do this }
thaumasiotes 7y ago
> I'd find it strange to encounter a config file with lots of internal documentation. This is hard to believe. Go ahead and open any linux config file.

karlicoss 7y ago

- sometimes the schema is strict (and you might not be able to control it) - you might not be certain if you break something with such a comment (i.e. you have to double check that all the "comment" fields are filtered) - you're not geting highlighting from your text editor, it's easier to miss a comment - you can't have a comment for a list item Basically, you can leave the comments, but you're really discouraged to do so. Most people would just give up and not bother.

worble 7y ago
I think the real loss here is that with a # or // the person reading the file immediately knows this is a comment. This line won't be read by the interpretor, and it's purely here for me to read it, so I probably should do. The following however { "comment": "Some comment", ... } Suddenly I'm not sure if this is meant for me, or if it's actually a configurable state without going into the program itself and checking if it uses it.
- Ididntdothis 7y ago
  Putting a comment into the payload is just a terrible hack. this shouldn't be necessary,

Ididntdothis 7y ago

Your "comment" is part of the data so it's not a real comment. I don't understand the resistance against adding comments to JOSN. This seems pretty silly to me.

u801e 7y ago

> Still don't get the hang up about comments with JSON. I'd find it strange to encounter a config file with lots of internal documentation. A lot of mainstream applications come with documentation in the sample config file that explains what each setting does and what its default value is. For example, this is the default configuration for redis[1]. Having that information in the config file guides users in terms of what's possible to change and what values can be used. [1] https://raw.githubusercontent.com/antirez/redis/5.0/redis.conf https://raw.githubusercontent.com/antirez/redis/5.0/redis.co...

wenc 7y ago

Commenting in complex configs is actually a highly compressed signal for communicating a lot of information without a lot of unwieldy external documentation. INI files support comments. apache.conf or any number of Linux config file support comments. Also, executable configurations are not uncommon. Consider .bashrc or .vimrc. And they're usually loaded with multi-line comments. Embedding comments in JSON fields gets unwieldy really quick for long configs. Compare: { "generalcomment": "the quick brown fox\njumps over the lazy dog", "setting1" : {}, "setting1comment" : "this is setting1", "setting2tree": { "setting2a": {}, "setting2acomment: "this is supposed to do this", "setting2b": {}, "setting2bcomment: "this is supposed to do this" }, "setting3": [1,2,3] "setting3comment": "to use this setting, do this" } To: // The quick brown fox // jumps over the lazy dog. { "setting1" : {}, // this is setting1 "setting2tree": { "setting2a": {}, // this is supposed to do this "setting2b": {}, // this is supposed to do this }, "setting3": [1,2,3] // to use this setting, do this }

thaumasiotes 7y ago

> I'd find it strange to encounter a config file with lots of internal documentation. This is hard to believe. Go ahead and open any linux config file.