YAML, for a couple of very specific reasons:

• It's reasonably concise. YAML doesn't waste huge amounts of space like XML usually does, it just uses exactly what's needed for structure and nothing more.
• It allows comments. This is honestly one of my biggest complaints about JSON. On any reasonable system, your configuration should be properly documented, and that's harder to do without comments. Also, lack of support for comments makes it hard to temporarily disable a segment of the configuration.
• It's not picky about quotes. Another complaint about JSON specifically, and some other config formats generically. Ihate having to remember what type of quotation marks to use around values that need quoted, and for that matter whether or not values need quoted at all. YAML makes this dead simple.
• In most implementations, it allows both full and partial reuse of segments of the configuration. This is a huge benefit when dealing with situations where you have to use essentially the same configuration for a bunch of things with minimal modification. YAML is a bit unique in that it's the only widespread config formats that lets you reuse the contents of a mapping while selectively changing only some keys.

If it's simple enough, I'll just set it as a bunch of environment variables in anrc file and be done with it.

If I'm working with python or javascript, I'll just create a dict or object in aconfig.{py|js} file.

For CI pipelines and deployment jobs, I'm kinda used to YAML because CircleCI and I guess the support for multi-line values is quite handy.

Otherwise I guess I would go for JSON, but I haven't had to do that in ages.

I've never understood how JSON was ever accepted as anything except datav transfer notation. One of the biggest misteries in life. I think it was too much of a rebellious drive from the despised by many XML and soap for datac transfer. Suddenly XML was the root of all evil in software.

XML is a bit annoying but functional.
Yaml needs some consistency work. Also I've found be lost inside the structure. Sources are not always the most recognisable element.

I like YAML but it often adds quite a bit of overhead as it's not as universally supported as JSON (many languages will need a library, some basic text editors won't recognize it, you can't pass it directly to your front-end, you can't display it nicely in Firefox...).

So if I don't need the advanced features of YAML I usually stick to JSON. It's just a shame that JSON was conceived only as a data format and thus doesn't support comments and trailing commas, because it would have been a really good configuration format.

Here's a poll I did last week. Most of the users preferred JSON

Davide Bellone 🐧

@bellonedavide

Imagine that#dotnetcore would allow config files to be defined in YAML, JSON or XML. Which one would you prefer?

07:04 AM - 03 Apr 2020

2 0

oh! I misspelled JSON

Due to lack of real life choices, I have to choose YAML, and sometimes,*.js; but I like JSON because

• Picky about quotes. Not being picky leads to unexpected behavior.
• Picky abouttrue,false

For anything that includes multi-line string, I would have to use YAML. Someone posteda nice tutorial a while ago... There is no alternative, if not for some indentation-based syntax...

I would suggest using the simplest format you can think of, and not create a complex hierarchical file format if you don´t need it.

If you can make it line-based it will be easier to query, concatenate, edit and filter from a UNIX-style command-line.

I use Yaml, and it's very simple to use

INI files. I like to keep my config files as simple as possible and nothing is simpler than a basic key value structure