At what point does a config file become a programming language?

Question

I have been mulling over config files and their relationship to code for a while now and depending on the day and direction of the wind my opinions seem to change. More and mor

Answer 1

I tend to agree with the premise of this question. I avoid getting myself into trouble by predicting early that this is going to happen, and therefore never roll my own config system.

• Either I use the operating systems' config facuility (such as a plist, or gconf or whatever is appropriate),
• Or a simple flat file, as can be handled by something like an off the shelf INI parser.
• Bite the bullet and plug a light weight language parser, usually lua, sometimes tcl into the application,
• Or store data in a SQLite or similar relational database.

And resign myself to live with whatever decision I made, or if i cant, refactor to use one of the above choices that better suits the application.

Point is, there's not really any reason to use a home-grown config solution. For one thing, it's harder on your users to have to learn a new, application specific config format. For another, You benefit from all the many bug-fixes and updates that come free when using an off-the-shelf solution. Finally, Feature creep is put to rest, because, well, you actually can't just add one more feature without really doing a major overhaul cause the config system isn't really in your hands in the first place.