XML is a bit verbose but otherwise easy to understand. JSON5 supports comments.
And neither requires me to explain weird formatting nuances to devops engineers.
YAML is a pain to read (lists of structures are very messy), can't be auto-formatted, and is full of weird "gotchas" (Norway, errant tabs, etc.) if you don't do things "the right way."
Requiring the use of whitespace in formatting is wrong. End of.
I instant exit on XML conf files. I have no idea how to parse the info, maybe I should. But there are too many tags and my eyes instantly glaze over when I see it!
Agreed about INI for simple stuff. Not good for arrays and nested things though. Usually use binary for that type of config (with clear documentation). Most binary config files I use are plain old C structures. I'm not a web person so no need to make the config plain text.
Using whitespace was a mistake. I know all the kids love it but it's just wrong. I've never had as much difficulty explaining json or xml to users as I have yaml.
We seem to have something in common: there is a serialisation form, we strongly dislike. But what I cannot understand is: why the heck would anyone torture anyone else to read or even write XML? XML is the absolutely worst configuration language I can imagine. I mean: when is something an attribute, when a tag on its own? What is even a list? And don't forget to include a full HTTP URI for the namespace, otherwise the tag is not defined.
By the way: all valid JSON is valid yaml as well. So in theory, you can use yaml as JSON with comments.
JSON if it also has an online schema, and a reference to it in the JSON file. That way some editors can check for errors and hint to the user about it.
But the good old flat text-data, the ini format is consistent, readable, and easily understandable by less-technical users.
If the purpose of the software is to work in closed, offline environment with Mr. NOTECH operating it via "line 5: rotations per minute; line 6: temperature in Fahrenheit" commands, then trust me, it's going to get the job done.
I like how elixir approaches it: configs are just elixir script files that have a module for some common conventions. Gives you a lot of power, and no goofy new syntax
That works if you have a small, disciplined team. As the team grows and it becomes harder to enforce standards, config files that are run through the language compiler easily get filled with programming statements that shouldn't be in a config file.
Assuming you can trust whoever wrote the config file, I prefer if it's executable code.
Not really fussed about what language. The point is it's really handy to have simple logic checks like a basic if statement on an environment variable. I also like being able to split my config files up into multiple files - maybe with an environment variable to check which files will be loaded in.