> I'm increasingly of the opinion that config files formats should be treated as a compile target not a file that you edit. I think this makes sense as far as

> I'm increasingly of the opinion that config files formats should be treated as a compile target not a file that you edit. I think this makes sense as far as it goes. The first choice, no matter what the config file format, should be editing within a tool. The tool can check values, be accessible, assist in coordination, etc. However, I think it's essential that the intermediate format be human readable and have the ability to contain comments. Because if something in the toolchain goes wrong, determining what the settings are right now on a particular system will be very useful. Being able to modify those settings by hand, though not your first choice, may save time and money and (depending on the system) lives. Also, if the tool breaks, you can still change configs (though obviously this is not what you want). Essentially, you should have a tool that edits config values with full explanations of their purpose. That tool should output a machine-readable format (JSON5, YAML, TOML) that supports comments with each value preceded with the comments containing their explanations and, ideally, a list of comments made when changing config values with previous values listed. You get the best of "both worlds."