Why is it a bad idea to write configuration data in code?

Question

Real-life case (from caff) to exemplify the short question subject:

$CONFIG{\'owner\'} = q{Peter Palfrader};
$CONFIG{\'email\'} = q{peter@palfrader.org};
$CO         


        

Answer 1

It's a bad idea to put configuration data in compiled code, because it can't be easily changed by the user. For scripts, just make sure it's separated entirely from the rest and document it nicely.

Answer 2

The main issue here is reusability in an environment where multiple languages are possible. If your config file is in language A, then you want to share this configuration with language B, you will have to do some rewriting.

This is even more complicated if you have more complex configurations (example the apache config files) and are trying to figure out how to handle potential differences in data structures. If you use something like JSON, YAML, etc., parsers in the language will be aware of how to map things with regards to the data structures of the language.

The one major drawback of not having them in a language, is that you lose the potential of utilizing setting config values to dynamic data.

Answer 3

There are many reasons to avoid configuration in code, and I go through some of them in the configuration chapter in Mastering Perl.

• No configuration change should carry the risk of breaking the program. It certainly shouldn't carry the risk of breaking the compilation stage.
• People shouldn't have to edit the source to get a different configuration.
• People should be able to share the same application without using a common group of settings, instead re-installing the application just to change the configuration.
• People should be allowed to create several different configurations and run them in batches without having to edit the source.
• You should be able to test your application under different settings without changing the code.
• People shouldn't have to learn how to program to be able to use your tool.
• You should only loosely tie your configuration data structures to the source of the information to make later architectural changes easier.
• You really want an interface instead of direct access at the application level.

I sum this up in my Mastering Perl class by telling people that the first rule of programming is to create a situation where you do less work and people leave you alone. When you put configuration in code, you spend more time dealing with installation issues and responding to breakages. Unless you like that sort of thing, give people a way to change the settings without causing you more work.

Answer 4

A reason I'm surprised no one mentioned yet is testing. When config is in the code you have to write crazy, contorted tests to be able to test safely. You can end up writing tests that duplicate the code they test which makes the tests nearly useless; mostly just testing themselves, likely to drift, and difficult to maintain.

Hand in hand with testing is deployment which was mentioned. When something is easy to test, it is going to be easy (well, easier) to deploy.