5 ms·
The solution for defining a more complicated config is to write your own config file format? I would think a custom format wouldn't necessarily be easier for ot
by Vitamin_Sushi 5y ago
The solution for defining a more complicated config is to write your own config file format? I would think a custom format wouldn't necessarily be easier for others to read and write unless it came with a guide/readme, but then that's just one more thing to learn. Admittedly, I've never had to write a super complicated config file, but can anyone tell me why I shouldn't continue to use something like JSON for all of my config files?
- beached_whale 5y agoLet’s not forget that almost every JSON parser optionally supports comments and trailing commma’s when parsing.
- simonw 5y agoWhich ones do that? I've not encountered many myself.
- Zamicol 5y agoAnd JSON5. https://github.com/json5/json5-go https://github.com/json5/json5-go
- simonw 5y agoWhat a delightfully readable example of a hand-rolled lexer and parser that is.
- jimmygrapes 5y agoI thought you were being sarcastic, but I think I just finally learned how lexers and parsers work by reading the code, and I don't even know Go.
- simonw 5y agoHah yeah no sarcasm intended at all! It's really neat code.
- thayne 5y agoRuby's supports comments. But that's the only one I know of
- beached_whale 5y ago* C# - builtin via JsonCommentHandling, JsonSerializerOptions.AllowTrailingCommas - Newtonsoft via CommentHandling, trailing out of the box * C++ - Boost.JSON/RapidJSON/DAW JSONLink have options for both, nlohmann has an option to allow comments * Python, I only know doing it via jsmin first * Javascript, use jsmin also These are the ones I have used or seen. It comes up so often that parser writers get issues over and over until they support them. nlohmann did not for years. But people want them for config files and such. Them being an extension is nice in that they are not officially supported and how they are handled isn't specified.
- u801e 5y agoCompared to yaml or ini formats, JSON is arguably harder to read and definitely harder to write due to having to keep track of brackets, commas, and/or quotes. Ideally, a configuration file should be easy to read and write/modify by a user of the application. A lot of applications just stick with ini like formats because it meets both requirements.
- secondcoming 5y agoMaybe it's because I've written C++ for years, but give me brackets over significant whitespace any day. If anything, YAML is harder to read because the indentation is important, yet deliberately invisible.
- Aloha 5y agoAgree. Whitespace with inconsistent rules is awful.
- benjarrell 5y agoFor me, the brackets, commas, and quotes are what make json readable (and writable). I really struggle to write yaml. I end up writing it as json and converting it. I agree about ini though.
- HelloNurse 5y agoJSON is unpleasant (for me, more unpleasant than XML), but at least it doesn't attempt to be clever like TOML and YAML.
- dragonwriter 5y ago> I really struggle to write yaml. I end up writing it as json and converting it. Since valid JSON is also valid YAML with the same semantics, it is impossible for it to be harder to write YAML than JSON, and no conversion is necessary.
- bwship 5y agoNot to mention being able to have comments in YAML. That helps make the file much clearer as well.
- thayne 5y agoTwo big reasons you shouldn't use json for config: comments and multi-line strings. json supports neither, although there are many other simple formats that do.