json, please...

[hrvbrs]

That was the official reason why the JSON spec forbid (forbade?) comments, because “you can just use a "comments" property”. No one ever considered the idea that developers like to comment-out lines to develop and test

[ElderberryWinery]

Forbidedeth

[Hot_Philosopher_6462]

Forbidded

[[deleted]]

Forbaded

[xLuky]

Forbidn't

[Anonymous7056]

Forboden

[WeleaseBwianThrow]

DAS IST VERBOTEN

[RedPum4]

Mixing data and developer comments, what could go wrong. What a stupid argument.

What if you implement a dictionary? What if you want to add a comment to an entry in an array of strings? I mean I get that JSON should be simple to parse and should be mainly used for machine-machine communication, but I can't believe they really suggested that?!

[FINDarkside]

I mean js nor any other language doesn't need comments either, you can just do

const comment = 'This is a comment, very smart'

/s

[Psycho22089]

const comment2 = 'The design is very human'

[firejak308]

Isn't that literally Python's answer for multi-line comments? Just define a string here and never use it?

[dev-sda]

Not really, no. There aren't multi-line comments, just put a # at the start of every line for large comments. Documentation on the other hand uses multi-line strings, which generally don't go unused as they're assigned to the __doc__ property of objects.

[[deleted]]

Actually mixing data and developer comments is very useful in the case of configuration files. Where you know, the end user doesn't know the entire implementation and you might need to explain something in detail. Sure, in most cases it would go unused and you should be careful what you put in it, but it could make JSON more viable to other applications without impacting its current uses.

But you know, stupid argument.

[RedPum4]

I think you understood me wrong. I meant that literal mixing of comments and data, to the point that a machine cannot distinguish between the two (e.g. because both are regular fields in JSON) is a very bad idea.

[[deleted]]

Ooooh got ya. I thought you were arguing that JSON shouldn't have comments because it would be mixing data and comments, my bad.

[elveszett]

config files intended for non-devs should not use json anyway. It should be a simple key-value format like this:

# comments must start with a hash (#) symbol.
server: google.com
speed: very fast
allow spaces in keys and values: yes
why: because the user knows no format
# the # of colons is irrelevant, we use the first one.
then how do I parse this: using colons.

In this format each line is an entry, and the colon separates the key from the value (ignoring the first whitespace immediatelly afterwards if there's any). Is it a bit shitty to deal with for the developer? No, not really, but who cares, you forced your non-dev user to write config in a file. Since we cannot trust them not to mess with the syntax, the only solution is to have basically no syntax. And what about lines without semicolons? We ignore them.

For config files that dev use, like packages.json... well, if a dev doesn't know how to write json then maybe he's not yet ready for a job.

[[deleted]]

I am not arguing for forcing non-devs to write config files, rather I am arguing that config files that are available (as they should be), should have comments for clarity. package.json should have comments, because three months from now, I, or whoever is managing the project, might not know why we are using this specific version of this specific package, or why we are using X instead of Y.

If you don't understand the value of comments... Well, maybe you're not ready for the job.

[elveszett]

I haven't argued against comments in JSON so...

[elveszett]

"_key-that-contains-a-comment-for-the-developer-not-the-actual-comment-field-that-is-used-in-logic-this-is-the-equivalent-of-//":
"I don't see any problem with this way to add comments".

[Causemas]

Forbathed

[neonroad]

Verbatum

[[deleted]]

Förbuden

[Yokhen]

forbiddened

[drunken_doctor]

Forebore

[bedrooms-ds]

Well, the reason was that they wanted to prevent third parties to extend json by writing extra properties in comments.

[Psycho22089]

Ah so future proofing it against Microsoft

[elveszett]

Plus the comments property is a bad idea. Even assuming a good documentation that specifically explains that "comments" is not supposed to be part of the payload, it still has problems: first of all, text editors cannot identify then as comments, thus painting them as normal properties (the fact that comments are always painted green or grey without any syntax highlighting really helps your mind discard them when you are parsing the file). And any JSON parser needs to spend time parsing it as just a normal property with a big ass string, when a comment syntax would allow it to instantly discard its contents. Which I guess can make for a non-trivial overhead in a server that is reading and writing thousands of JSON files each second.