
Global variables are bad (2013) - nilsocket
http://wiki.c2.com/?GlobalVariablesAreBad
======
__sr__
Are they really? I agree that global variables are horrible in a language like
C where they are truly “global” because of the lack of namespaces. But in a
language like Python, they are tolerable because they are not truly global —
they are restricted to the particular module. I am not saying they are great,
but they are not as horrible as they are in, say, C. Of course, care must be
taken to ensure that they are abused, but that is true of any programming
construct.

If module global variables are considered truly horrible, the same can be said
about instance variables inside classes. They are as good (or bad) as module
globals in the sense that they represent shared state and can potentially be
mutated by any method/member function in the class.

Of course the functional programmers among us will say that shared state of
any kind is bad, and I agree. But we are not talking about that here, are we?

~~~
LolNoGenerics
I don't think anyone argues variables with module scope. Because as you say
they are not global.

~~~
cakoose
Mutable variable that have exactly one instance (globally) cause some of the
same issues, which is why people might casually lump them in with "global
variables". (It would be nice if everyone used more precise terminology,
though.)

------
drblast
It's funny how much I dislike the top two alternatives to globals, at least
how they're typically implemented today. For me it's a case where the cure is
worse than the disease.

I've worked with a codebase where the global state was passed around as a
configuration object, and that made heavy liberal use of dependency inversion.
No other code base I've seen was so obtuse...it was nearly impossible to know
what a line of code did but looking at it.

Dependency injection and configuration objects certainly can be useful, but
the bad design they seem to encourage makes me think very carefully about
using them.

~~~
AstralStorm
It is still global state, albeit better boxed and automatically attached to
places that need it.

If it is mutable, you have even more problems.

About the only way to deal with this is to strictly enforce contracts and
completeness when using and implementing such a thing.

------
bluetomcat
I'll play the devil's advocate. Global (shared) variables are fine when they
represent non-instantiable program state and have descriptive names, with a
clear semantic contract for mutating their state. Essentially, something like
`the_world.rotation_speed` is a good example.

~~~
mpartel
What if you, one day, want multiple worlds for some reason?

I'm developing a game in Unity, and the programming culture around it
encourages globals and singletons to an unhealthy degree. I pushed back
against them heavily in our project. As a result, it was very easy to add a
previously unplanned split-screen mode one day, thanks to the codebase (e.g.
the UI and input modules) not assuming that there's only ever one local
player.

~~~
JimDabell
> What if you, one day, want multiple worlds for some reason?

Write code for the application you want, not the set of all applications you
might hypothetically want someday. Incur the cost of new features after you
decide you want them, not before.

~~~
mpartel
In general I fully agree, YAGNI and all that, but from experience, mutable
globals, unless used _very_ sparingly, rigidify the codebase to a surprising
degree and make it more error-prone, often for very little actual gain.

As with any software engineering guideline, there are exceptions. E.g. Java-
style loggers are so ubiqitous and "not that mutable", that it's generally
good for them to be global.

Edit: also from experience, suddenly wanting two of something where before
there was only one, is not that uncommon.

------
HumanDrivenDev
What is with all this contrarianism against basic software best practices in
tech circles these days? First the thread about how great copy pasting was,
and now people praising the use of global variables. What's next - goto
advocacy? Segmentation faults as the preferred error handling technique?

~~~
jimjimjim
gotos are fine.

people are tired of guidance being turned into rules and then into dogma.

~~~
notacoward
I wouldn't say gotos are fine, but they're sometimes better than alternatives.
I'll take a "goto" to an error-cleanup cascade at the end of a function over
ten nested three-line functions, a mini state machine, or lots of little state
variables (the most common alternatives) any day. If the language has
destructors or deferreds or anything else that automatically triggers when
leaving scope that's probably even better, but some older languages - notably
C - don't, so dogma often leads to worse alternatives.

------
jameslk
I guess this is pretty basic, but it creates tight coupling between unrelated
code, as described here:

[https://en.wikipedia.org/wiki/Coupling_(computer_programming...](https://en.wikipedia.org/wiki/Coupling_\(computer_programming\)#Types_of_coupling)

------
LeoPanthera
I use global variables, though usually as constants, to hold the command line
arguments to my programs.

I don’t know if this is “good” or not but it seems to work OK.

~~~
partycoder
Then those would be global constants not global variables.

~~~
kyberias
In many programming languages, "constants" are compile-time and therefore
cannot be used for holding command-line parameter value.

~~~
partycoder
The only invariant of a constant is that it remains constant. The way that
abstraction is represented is implementation specific.

Compiler generated constants can still change, because registers and memory
are mutable.

------
FrozenVoid
Global variables are fastest, least memory intensive way to transfer state. If
you need thread safety, atomic variables are still faster and more efficient
than any alternative. You can create pseudo-namespaces in C like Global_ and
avoid name clashes too.

------
dingo_bat
> Really Bad Reasons to Use Global Variables > "I don't want to pass it around
> all the time."

This is not a bad reason at all. I think this is the best and most used
reason. And no alternative is provided in TFA.

~~~
oweiler
I disagree. Passing around variables, while unpleasant, at least makes
dependencies explicit.

