Configuration Parameter Heuristics

The following heuristics are useful when designing configuration parameters.

• Make them easy to change, even when the rest of the system is down. This means storing them externally, in a simple, easily managed, nonbinary format.

• Store all of the data in one location. If you think you must have them in multiple locations, find a person you trust and convince them that storing the data in multiple locations is a good idea. If both of you continue to think this is a good idea, go ahead and do it. If you are lucky, your trustworthy friend will convince you that this is a poor design choice and will help you choose a better one.

• Store the file in an obvious location with an obvious name . I recommend names like "System Configuration Data" and places like the root directory of the installed application.

• Platform-specific file formats, such as .ini , are okay, but why not use XML? It's simple, as verbose as you need, and easily managed.

• Be careful of things like registry entries. They aren't portable and can be difficult to change for nontechnical users. I don't see a lot of value from use of the registry.

• Make configuration data easy to capture and forward to technical support. It's amazing the number of problems a sharp technical support person can solve once they understand how the system has been configured.

• Make it hard to get the values wrong. If they are wrong, notify the user as soon as possible and either stop execution or continue with sensible defaults.

The most resilient designs are based on the idea that configuration parameters are persistent attributes of some entity or object. This enables other objects or subsystems to deal with the information within this object and not worry about how to manage INI or XML files. Because these attributes can often be affixed to different objects, the tarchitect should consider that any of the following may be useful.

• A system context object, for storing information about overall system context

• Per-computer, per-service-instance, per-user, or even per-selectable-user profile objects

• Objects that capture the semantics of the configuration data

Keep in mind that, while you don't have to get all of the configuration data you need right at the beginning of the system, retrofitting can be cumbersome, and may require architectural changes.