Post History

I would like to add further options to the set of possibilities, namely _environment variables_ and _GUI input_.  Moreover, I would like to distinguish reading information from `stdin` and from other (named) files, as this has some architectural implication.

With the options from the OP and other answers taken into account, this gives the following set of possibilities how configuration input can be provided to an executable:

* Command line arguments
* Environment variables
* Non-interactive input via `stdin` (typed in or via file re-direction)
* Input file (opened by name)
* Interactive input via `stdin`
* Interactive input via GUI

All of these options have their justifications depending on the circumstances, and it can even make sense to combine some of them - for example providing the name of some configuration file via command line or in an environment variable.

Among the decision criteria - some of them have been mentioned by others - are the following (and for different use cases your answers and the resulting tradeoff will be different):

* What is your user base, are they interested and likely capable to automate their use of your program?  Do they need guidance while providing the data?  Shall they be able to correct mistakes during entering the data?  If this is the case, some interactive form of input is preferable.
* How complex is the data that needs to be provided?  Is it simple numbers or nested, possibly even recursive data structures?  The more complex, the less suited are command line arguments, environment variables and interactive console input.
* How much data has to be provided?  For large data, command line and environment variables can not be used, as there are system limits on their sizes.
* How many individual data items have to be provided?  It is not advisable to have lots of environment variables, due to the system limits but also due to the increasing risk of name clashes.
* Is the possibility to automate your program relevant?  GUI input is hard to automate, interactive console I/O is easier, but non-interactive forms are easiest.
* Is it desirable to have several levels of configuration, like, system configuration in a file like /etc/<system-cfg>, user configuration in ~/.<user-cfg>, shell session configuration in environment variable, process configuration on command line, final changes made interactively?
* Is your configuration meant to address your program as a whole, or maybe just some library you use?  With environment variables and configuration files you can provide data directly to libraries (bypassing the main program),  If you provide data via command line or via stdin, the main program is always involved and has to forward the data to the library (this is the architectural relevance of stdin mentioned above).