Many applications allow for some level of configurations, ranging from the location where the log files should be written to the connection settings of a database to application specific parameters. But with configuration comes an extra level of potential error. What if the configuration (probably file) is not specified, what if there is an error in the configuration, and should you force the user to set all of these configuration values?
All of these are important decisions that need to be made and they can not be neglected. I will discuss a couple of different views and options you have and what are their benefits and drawbacks.
A common approach is to have default values for every parameters in the configuration. This allows an out-of-the-box installation of the application without any special configuration needed. I like this idea as a user doesn’t need to go through a complicated configuration step where it configures everything that needs to be set. It does however obfuscate the actual values and may make it harder to know what the actual default configuration is. Good documentation is essential.
The complete opposite is to have no default configuration and everything needs to be explicitly specified. This gives the user full control over all of the settings and he will be made aware of how it is configured as he himself has set it to be so. This does however an often very cumbersome step which will take some time before the application can be taken in use. It can be frustrating for a user if he has to set values which he believe should be default (such as a local database connection).
Anything in between, where the user has to specify some configuration values is possible as well, but only make sense if you want to have default values but for some parameters it doesn’t make sense to enforce a certain default as it would be different for each user.
This handles configurations where certain parameters are missing, but what if the configuration (file) itself is missing or contains a wrong value? If you have default values for each parameter you can fall back to those, otherwise you can’t do anything but terminate the application with a clear message. An error in the configuration can be handled the same. However using default values in this case is less transparent for the user as he believe to have set certain configuration parameters. A clear message somewhere to indicate that the configuration was not set/valid is essential to notify the user.
A special case, and it is one I really like, is when your application allows on the fly configuration changes. Most often you want to do this with some nice GUI, which will eliminate the risk of mistakes being made, but if this is not possible and you want to handle on-the-fly configuration changes coming from somewhere else (like a file) is a lot harder. Since the application is running, you will not to either pause it, which may not be feasible, or parse the new config in the background and swap it in one go after validation. Again the question is what if the new configuration is not valid? Do you want to abort the application? It would make it very clear to the user that the new configuration is wrong, but it will also suspend any activity that was going on. A simple log line may go unnoticed but could be the best you can do to prevent any undesired interruptions.