With time you start to see problems with doing things a certain way. And I have come to see a problem with environment variables. This post will be mostly me bashing on them but I also see how when used correctly they can be supper useful.
What is an environment variable? They are variables that are set at the system level. On a Linux and possible a Mac system if you open the terminal and run printenv you will get a list of all the current environment variables set in that shell(terminal). A short hand for environment variable is envvar.
Now that we know what a environment variable is, whats the problem with them. To start somewhere lets talk about the shell. A shell runs in a terminal and you can have multiple running in a terminal at the same time. How I like to think about it is the terminal is like a web browser and the shells are tabs within the web browser. So the problem if you set a environment variable within a shell, it is only accessible from that shell. Any other shell does not have it. If you wanted all shells to have access to the envvar you would need to add it to the .bashrc file (if bash was your shell). Even then any opened shells would not have access. Opened shells would need to reload the .bashrc file to have access or be closed and reopened. Updating a environment variable has the same problem, it is only updated in the current shell. This can lead to a case where you might be trying to run an application thinking the environment variable are set correctly while they may not even be set at all.
Next problem, what do you call your environment variables? If you have done any amount of development work you will have learned that naming things is hard. Any environment variable name has to make sense and it needs to relate to the application that is using it. But why does the name matter so much? The environment variables are global, any application can access them. This means any poorly named variable could also be used by a different application. While this might cause expected behavior in your application there is no telling what might happen in third party applications.
While this next problem is also a plus for environment variables it is deferentially the cause of some issue. Easy of access. If your a developer and you want to allow some section of your application to be configurable, environment variables make this so easy. Any language that I have used had built in ways to access these super envvars. And that's the problem the easy of access causes them to be over used within a code base. At the time ya, there is no problem but over time people start using and accessing the same envvars from all over the code base. No one knows what the initial reasoning behind the envvar and now it's baked into the system. Which means removing or renaming it is near impossible. The ease of creation and access of the environment variables make them real good for a quick fix but there is no such thing as a quick fix, only a long death(technical death).
So what is good about them? It is the fact they are so easy set and access. This makes them very powerfully. But you need to be use them sparingly. Environment variables are very good for doing quick changes in an application. This point I am on the fence about, there are better ways. They are system wide, if you need to effect more than one application at a time this is a good way.
At what point do we need to talk a step back and ask our selves are we using environment variables incorrectly. I think this number is three. When your project has more than three environment variables there is a problem. I want to say one but realistically three is a better number. You might think three does not seem to bad but I mean only three for the entire project not just the application that gets shipped. If there is helper scripts, build command, the application, any thing in the project repo that access a environment variable counts. Now the three becomes a very small number. If you think a script that is only every called with inline environment variables is okay it is not. You don't know what optional variables for that script has been set on a different developers system.
Now that we know using environment variables is a bad idea what can we do about it. I'm working on it. There is a few ideas in my head and I can guessing you should look at this tag to see related posts but I do think the answer is to pass a configuration file to the application or script.
