Don’t use environment variables for configuration

sure env vars are overused. some values simply do not belong in the environment, for example - credentials. however, i havent seen a more convenient method of injecting configuration dynamically without some error prone file watching mechanics

The author says: // to call it you'd do

first_argument = 1;

second_argument = 2;

int three = add_numbers();

This is, I trust you all agree, terrible. This approach is plain wrong.

I agree, but I don't think everyone agrees. Just have a look at the apple APIs, their configuration options are all objects you have spend time configuring, then pass as an argument. I don't know why everything with Apple development beats around the bush. It's almost too object oriented.

To be clear, Apple is more like this:

let argument = Argument()

argument.first = 1

argument.second = 2

let addRequest = AddRequest()

adder.add_numbers(with: arguments)

let mathRequest = MathRequest()

mathRequest.perform([addRequest])

if let results = addRequest.results {

    // Do something with your results.

}

And yes though, Apple development makes me feel smart when I solve something that should've been documented.

Strongly disagree. Environment variables are, IMHO, best tool for some simple configuration in unix. They match perfectly with behavior of the ecosystem and other tools in it (like unix shell).

Yes, if your OS is some unversal JS machine, then JSON would be better, if it is Lisp machine, then you would use S-expressions, but on Unix machine, environment/args are way to go.

There are two realistic alternatives - config files and arguments. They have each their own niche, where environment is somehwere between them.

Arguments are better for one-shot setting, not for some setting used always. You can use 'alias' to define shortcuts that always add some argument, but that is definitely more cumbersome.

Config files are good for always/default setting, but are too rigid. Changing config files is equivalent of changing global variable in code, it has system/user-wide effect. While i can just change environment in this one shell and it will affect just commands executed from that shell. Also, config files are much harded to be manipulated from scripts, and use different syntax for each tool.

Perhaps the ideal tool would allow every option to be set/changed from config file, environment and argument.

> Just because something has been used for decades does not make it good.

I'm not calling this is good with the persistence of the original author. I tell that it's one of the realities that we have, and instead of burning it with torches, why not build better conventions around it with better attitude and language?

Maybe we can try: "Instead of burying all config under environment variables, why not try doing it like this?", and slowly build something better, step by step. Nothing is inherently good or bad, but can be abused. So the abuse of environment variables as a shortcut needs to stop, one may say and I'd agree, and may also volunteer to help to build a better thing.

But, shunning it with anger and shouting "I'm the one who knows all right things!" sure creates backlash, like here.

All in all, I'm against the attitude, not the idea of improving a situation.

> Yes, some things are bad and are actively harmful.

It might be, but even your solution might not be right. Why the attitude?

> unstructured programming using gotos. Would you like to go back to that?

Did that on some older, limited hardware, and it was fun. It was not OK by today's standards, but I had to. I'll do it again if it's the only thing I can do to work on that particular hardware again.

> But perhaps you are not a programmer?

I just design algorithms and develop scientific applications which run on HPC clusters, nothing fancy.

> It's not a "de-facto standard", it's simply bad.

I didn't say it's good. I say it's a fact. I'm not disagreeing on its bad sides. I'm not OK with the attitude.

Storing the name of an "environment" in an environment variable and then using that to pick the appropriate configuration file is what .Net Core does for web apps and that seems to work fairly well.

Then, of course, you have the fun of Azure Application Configuration and KeyVaults - which are fine once set up and your app is happy with them.