[drig]

I always use an in-between system. My configuration library allows me to set a default, if the parameter is not found in the config file. I always set a reasonable default, and then only override if necessary. This keeps the configuration files small, keeps the default value with the code, but allows you maximum flexibility, just in case.

[jvoorhis]

Another tactic that has worked well for me is to expose a flat namespace of flags and tunable parameters in config while shunning instantiation of complex object graphs. Complex nesting in configuration tends to be too "raw" for users and sysops, and hurts usability.

[markbernard]

I do the same. I also keep the configuration centralized so all access goes through one class. I also allow defaults in the config file along with specific values based on what environment you are, such as production or UT, etc...

[zbuf]

I've found this method invaluable where we are centrally supporting the same software in multiple environments and in multiple configurations.

[zwieback]

That's the correct approach, in my opinion.

[ashmud]

We do this. For bigger apps, we usually have a db layer, so local config file -> db config -> default in code.