When you write a program, you make many assumptions.

An assumption could be for example the location of a file.
Or the colors of the output.

This assumption could be that errors are always displayed in red.

<pclass="error">this is a mistake in red</p>

.error{color:red}

Now, not inevery culture the color understanding is identical. Also, there arecolor weaknesses or simply preferences of the users.

One could compile different programs now. One for each color scheme. But that gets confusing pretty fast. What can we do?

So, we make it configurable.

I use pseudo code in the examples, not a concrete programming language.

.error{color:${errorColor}}

As soon as you are not sure about the standard or find a person who wants it different, make it configurable.

We have replaced aliteral with a variable here.

How do we set this variable now? The default value will look something like this.

errorColor='red'

How can we make our program configurable?

Command line?

The simplest form is the command line.

Via a flag, we could expect the color value.

my-tool--color=red

The pseudo code then looks something like this:

if flag[color] != "" then   errorColor=flag[color]end

Smaller tools can be controlled well from the command line, but for many applications you don't want to always specify default configurations.

Why files?

If a program has many setting options, it quickly becomes confusing.

Reading values from files allows us to set these defaults once.

There are several formats to store configurations. Each format has advantages and disadvantages.

Here are a few formats, without claiming to be complete.

• YAML
• TOML
• XML
• INI
• Properties

we can now define values via the command line and specify more global standards via a configuration file.

The format is really a matter of taste. Some programming languages have favorites, but for the popular languages there are parsers for each type.

I, personally, was a fan of XML for a long time, as it is very precise and concrete, but lately, I actually always prefer YAML.

YAML is from my point of view the clearest for the user. Of course there are problems here like theNorway problem. But you can work around them.

However, sometimes you want to define values centrally in an environment, which may be valid for several programs.

This is where environment variables come into play.

Environment variables?

As the name suggests, environment variables define a certain value in the environment in which the process was started.

This allows easy and quick adjustment of standard values.

An example is the variableLANG, which defines the standard for determining locale categories.

echo$LANG> en_GB.UTF-8

Configuration weight

If we have multiple sources of information, we need to determine how to evaluate the sources.

Which value is taken?

Essentially, we have a chain. As a basis, we take the value in the program.

The weighting of the individual sources must of course be adapted to the application.

The code could then look like this:

errorColor='red'if flag[color]  != "" then   errorColor=flag[color]elseif env[COLOR] != "" then   errorColor=env[COLOR]elseif file[color] != "" then   errorColor=file[color]end

If a value is passed on the command line, it overwrites all other values. Why?

Because the value is more immediate than a value in a configuration file.

Because we assume that the user wants to use this value now.

So much for that. Have fun configuring!