3 ms·
My biggest problem with using JSON, apart from the needless quotation marks on identifiers, is the lack of comments. Any human-editable format (like using .json
by MichaelGG 10y ago
My biggest problem with using JSON, apart from the needless quotation marks on identifiers, is the lack of comments. Any human-editable format (like using .json for project config files or build files) should have comments.
- tracker1 10y agoI'm in favor of using YAML [0] or INI [1] formats when a file is meant to be edited by a user. YAML is close enough to JSON, but does support comments, and the structure is a bit cleaner for user editing. [0] https://en.wikipedia.org/wiki/YAML https://en.wikipedia.org/wiki/YAML [1] https://en.wikipedia.org/wiki/INI_file https://en.wikipedia.org/wiki/INI_file
- TMSZ 10y agoThere are few ways of inserting comments: http://stackoverflow.com/questions/244777/can-i-use-comments-inside-a-json-file http://stackoverflow.com/questions/244777/can-i-use-comments... If you do not care too much about exchanging data with other apps then parser/generator supporting javascript style comments (e.g. json-cpp) would work. With each JSON value it can store "commentBefore" and "commentAfter". If you need you can strip these comments any time by parse + write cycle with "collectComments" option inactive.
- MichaelGG 10y agoAdding data and calling it a comment isn't really a comment. And I find the whole "run minifiy/strip first" to be a hilarious suggestion from Douglas Crockford. It can be rephrased as "If you want comments in JSON, for a config file say, then don't use JSON." That, and XML requiring the tag name in the closing tag, are some of the obvious, silly, mistakes. XML in particular. Without the named closing tags, just using, say, <>, would reduce the apparent bloat and annoyance by a very large factor.