Thoughts on this: * Config should never, ever be written by the application which depends on it. Ever. I don't care what you think your rationale is: no applic

Thoughts on this: * Config should never, ever be written by the application which depends on it. Ever. I don't care what you think your rationale is: no application should modify its own configuration. - Git is a weird case which springs to mind, but technically `git config` is separate from eg. `git fetch`. So no real problem there. - .NET's bidirectional config bindings are daft. If you stick to reading only then the framework's fine, but otherwise it rapidly heads into crazytown. - If you think you need to violate this rule, probably your 'config' is actually user data. If so it should be treated as such, ie. it's subject to data migrations, the admin doesn't need to touch it during upgrades, etc. * Config needs to be strict. It must be possible to statically verify the basics, and there should not be any confusion over meaning in eg. some random diff. - Everything's a string in a text file. The way in which the string is interpreted must be absolutely unambiguous and sane. - YAML need never apply. * Config must not be Turing-complete. Ever. If your configuration can be every conceivable output of a program then you have built a system which is effectively impossible to properly test. - I take this one step further and consider it idiotic to include code in a config file at all. It's fine to generate one from other files as part of a deployment, but the config read by the application fucking better be a single static text document which maps to a simple data structure, with as little processing as possible performed after the fact. * Config needs to be possible to process in a totally reliable way by a deployment process, eg. templating. - See above. * Config should succinctly describe concepts which make sense for configuring the application, not the dozen or so libraries upon which it depends. - In .NET terms, this means "don't give us ten megs of 'default' WCF crap to fiddle with". Give us an endpoint address, and sufficient documentation/logs/etc to figure out why 'http://something' http://something' doesn't work for an app written only for 'net.tcp://something'. - Logging is a weird one. I'd generally handle this by providing app-level levers for expected logging requirements, then explicitly calling out the framework and version used and where to find the docs for the advanced stuff. Given the above, I fail to see anything at all wrong with XML. It has strong support for schema validation and templating, and can handle any complex data structure it needs to in both contexts. Saving keypresses is not a valid excuse. Terse crap is still crap.# While longwinded pointless junk has given XML a bad name, particularly in the Java and .NET world, being explicit about things retains stability in the face of supposedly-unrelated changes: if your configuration's meaning can change globally if a single rule or heuristic is modified then your software's reliability is in question. All it costs is keypresses, and text diffs are very easy to audit in source control. Write compact config in anything you must, generate the big stuff, commit it, record it, audit it. And have CI check that the compact matches the big. Disclaimer: ten years ago I hated XML for wasting so much space. I was an idiot. These days I'll take abundant permanent precision over everything.