Hacker News Reader

Comment by Vitamin_Sushi | Hacker News Reader

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?

View on HN

Compared 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.

Maybe 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.

Agree.

Whitespace with inconsistent rules is awful.

For 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.

JSON is unpleasant (for me, more unpleasant than XML), but at least it doesn't attempt to be clever like TOML and YAML.

> 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.

Not to mention being able to have comments in YAML. That helps make the file much clearer as well.

I prefer JSON to YAML. There are no objective way to measure whether one is better than the other.

Two 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.

Let’s not forget that almost every JSON parser optionally supports comments and trailing commma’s when parsing.

Which ones do that? I've not encountered many myself.

And JSON5.

https://github.com/json5/json5-go

What a delightfully readable example of a hand-rolled lexer and parser that is.

I 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.

Hah yeah no sarcasm intended at all! It's really neat code.

Ruby's supports comments. But that's the only one I know of

* 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.

Reply on news.ycombinator.com