this post was submitted on 01 Feb 2024
43 points (86.4% liked)
Programming
17270 readers
39 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Where do you put your comments in JSON files?
I've seen them included as part of the data.
"//": "Comment goes here",Example here.
That doesn't really work when you need two comments at the same level, since they'd both have the same key
write json with comments. Use a yaml parser.
If you're reaching for yaml, why not use toml?
Every time i try to use toml, i end up going back to json
because of the cut and paste problem. It works in json.
Cut and paste problem?
cut out a random piece of your document. is it a partial or a complete document?
paste it somewhere else in the document. you have to fix the indentation because if not then the document won't work or mean something completely different
Whitespace has no meaning in json. You can indent however you want, or not at all.
I'm assuming you're running into issues because you're writing json in a yaml file which does care about indentation, and you're only writing json in yaml to get access to comments.
In which case it circles back around to: why not use toml? Whitespace formatting doesn't corrupt the file, and it has built in comments.
i do use json instead of yaml precisely for the reasons you mentioned. That was my original point in the first place that json does not have these problems. something must have been lost in transmission
It still works since multiple identical keys are still valid json. Although that in itself isn't fantastic imo.
For settings files I always have an example file with sensible values filled in and along with descriptive keys that serves as reasonable documentation. If something is truly unknowable, I’ve probably done something wrong.
How would you mark a flag in your json settings file as deprecated?
In my opinion, the settings file isn’t where this information should be presented. I would put these notes in the release log and readme and example settings file. I have also written this information to logging during startup so a user knows what to do, or I write a migration that does the change automatically if that’s possible.
This is only my opinion and you can use the comment method described like
“//“: “Deprecated”if desired.