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

Config file: "What is my purpose?"
You: "Configure the butter."
Config file: "Ok..."
Config file: "What is my purpose?"
You: "You configure butter."
Config file: "Oh my god."

1. There is no "true purpose" of a configuration file. Its whatever makes sense for your application. In general, things that differ (or might differ) between machines and don't change in the middle of your application run should probably be in a configuration file. Defaults, ports, and addresses for other services are all great candidates. Keys and secrets are also great candidates but should be handled separately from your normal config for security reasons. I disagree that the purpose of a config file is to allow quick changes to be made. The purpose should be to allow flexibility in the setup of your application. If a config file is a quick easy to way to allow that flexibility, so much the better - but you should not be intending your config files to be frequently changing.

2. Yes and no. Should you atempt to make your application's code simple? Yes. You should attempt to make everything you write simple and to the point. No more complicated than it needs to be. Same is true of your config. However, this is very application specific. Hardcoding what should be in config because it would make your config "too complicated" is bad design. In fact, trying to "keep things simple" is why config files end up being a giant mess. Sometimes the simplest move is to modularize. This is why your configuration files should be written in a well known general purpose programming langauge - not some terrible configuration language (read: all "configuration languages" suck).

3. Again, who should be modifying config files is completely application dependent. But I agree with miniquark, whoever is deploying the application should be in charge of the configuration.

4. Source control everything you can. Source control is great. You can roll stuff back super easily and you have a full history of the changes you've made and a record of who made those changes. So why not?