What's Wrong With Global Variables?

Only lazy people haven’t written already about how global variables
are evil. It started in 1973 when W. Wulf et al. claimed that
“the non-local variable is a major contributing factor in programs
which are difficult to understand.” Since then, many other reasons
where suggested to convince programmers to stop using global variables.
I think I read them all,
but didn’t find the one that bothers me most of all: composability.
In a nutshell, global variables make code difficult or impossible to compose
in ways which are different from what its original author expected.

What do you do if you want to start two web servers?
For the purpose of testing this may be a pretty logical requirement.
For example, since Zold is a distributed network,
it is necessary to test how a number of servers communicate to each other.
I can’t do that! There is absolutely no way.
Because Sinatra is designed with the assumption that only one server may exist in the entire application scope.

Can this really be fixed? Let’s take a look at their code.
Class Sinatra::Base is essentially a Singleton,
which is not supposed to have more than one instance.
When we call App.set(:port, 8080), the value 8080 is saved into an attribute of a single instance.
The number 8080 becomes available for all methods of Sinatra::Base, no matter what instance
they are called from.

They are not using true
Ruby global variables, I believe, because they know that they are bad.
Why exactly they are bad and what the
alternatives are—slipped through their fingers.

Technically speaking, their design is “globally scoped.”
Sinatra::Base treats the entire application as its scope of visibility.
No matter who calls it, everything is visible, including what was created
in previous calls and in previously instantiated objects.
This “class” is a giant bag of global variables.

Every global variable is a troublemaker of that kind.
While the application is small and its test coverage is low, global variables may not hurt.
But the bigger the app and the more sophisticated its automated testing scenarios,
the more difficult it will be to compose objects which depend on global variables,
singletons, or class variables.

My recommendation? Under no circumstances even think about any global variables.