Is global state really always bad?

Question

I have a question regarding my general understanding of global state in software engineering.

When I write an app I like to decompose it into little, manageable components and functions, that are ideally self-contained, have their own local state and don't produce any side effect.

But some types of those functions seem to be inherently tied to some sort of global state, yet global state seems to be globally banned - excuse my pun - among software engineering folks. Usually they will tell you that "you can't reason about global state, that's why it's bad and you must not use it".

A primary example of an inherently global state of an application is the authentication status of a user. How can any solution that handles such global state possibly be inherently better than something like a global, public, static class or just global variables that can be accessed from anywhere in the app to check for the user data?

It just seem so convenient to have global variables for some types of data, yet they get so much hate and are always advised against. What is truly the underlying issue behind them other than "they can't be reasoned about" whatever that means? I know concurrent writes could be an issue but not all types of data are constantly or even concurrently written to?

Answer 1

I think you are conflating two (surely related) things here: global state, and global variables which are accessible from everywhere in a huge application. An application can have global state without global variables, but global variables almost inevitably introduce global-application wide state.

• Global state becomes an issue especially when the state is mutable. For example, the authentication status of a user, or even worse, the connection status for a database application: when this state changes during the runtime of an application, all kind of unpredictable things can happen when an application does not have in-depth error handling at all kind of levels.

  Unfortunately, in a typical DB application, you cannot really avoid this global state to change from the outside - when someone pulls the network plug, the connection will be gone, and the state will change, if one likes it or not (for the sake of this example, put aside failover mechanisms which handle such issues in the background).

  However, something like the authentication status might be set only at the start of an application, and kept as immutable during the rest of the application's lifetime. Such (almost immutable) global state is way easier to deal with, since large parts of the code are usually not affected by it.

  You find more information about this topic in this older SE.SE question: Why is Global State so Evil?

• Global variables (or its cousin, a globally visible static class with internal state), however, become usually a problem under the aspect of testability, maintenance and evolvement. When you design a module or component with a clear interface - for example, where it gets something like a "database connection object" passed into, you make this dependency explicitly visible for anyone who has to deal with the component. Moreover, one can mock it out for the purpose of automatic testing.

  When you use a global variable instead, the dependency becomes hidden. That may not be a huge problem for smaller applications, but when an application system contains several hundred thousands lines of code, it becomes sooner or later a maintenance nightmare. Whenever you want to change something here (like allowing to be connected to two different databases at the same time), you will have to audit the whole application code and may have to change it in thousands of places - good luck.

Answer 2

It is not a problem as long as the clients of the global state are not reused outside the context of the application and the nature of the application doesn't change too much.

The problem is that you will have a (probably backwards) dependency that could be avoided by injecting an interface to the state into the client. Say you have a class Program that creates a form, which creates a number of controls that all need that state. Program has this static GlobalState member. Sure, you could reference Program.GlobalState from anywhere, like from all over your form and controls implementations. But this would require your form and controls to know about that particular Program class which would be, quite literally, backwards.

Now, granted, if your object hierarchy is deep, preventing the global state would require you to pass the state interface in a lot of places which does not make your argument lists any prettier. So there usually is a trade off. Can you be sure there will always be one state, now and forever?

If it ever gets a problem it would be easy to fix. So you may want to shut up any purists with "YAGNI"!.

Answer 3

When you make something global, you force there to only be one of it.

You say that user authentication status should be global. Then what happens later, when your customers want to be able to log in with two user accounts at once, and switch between them? You keep a backup copy of the authentication state and swap it with the real one? That's asking for bugs.

But your customers aren't asking for that yet. You do want to make an app where, for now, the customer can only log in with one account. Obviously somewhere in the app is going to be a variable for "the account". But you want that to be pushed as far out as possible. You want as much code as possible to assume there could be more than one, so that later when there is more than one, you won't need to change it. Instead of writing void RefreshAuthenticationToken() you write void RefreshAuthenticationToken(Account* account). And even the "log out" button has an Account passed to it, telling it which account to log out when it's clicked on. Only the top level, that ties everything together - the Composition Root - should know there's only one account. Then, when you want more than one, you only have to change how the different parts are tied together.

---

Everyone knows Minecraft. Minecraft used to have this problem - there was the game world, there was just one, and everything referred to it. But then, they wanted to add an alternate game world (called "the nether") that you could travel to, by going through a portal. The solution was to put The Nether in a separate save file. Whenever the player travelled to The Nether through a portal, the game would essentially delete the player character from the game world, save and quit, load The Nether, then create a player character in The Nether with the same information it previously deleted. For obvious reasons, this doesn't work in multiplayer mode (there can be several players and each one in a different world), so multiplayer didn't support The Nether for several months. Eventually, every function that cared about the game world had a World parameter to say which world, and then both worlds could exist at the same time.

If it was written that way to begin with, the only part of the game that knew there was only one world would be the part that loaded a save file. To create The Nether would've been a lot easier, that part could've been made to load two worlds from a save file instead of just one. It would've worked in multiplayer from the beginning, too. They could've just done new World().setName("The Nether").setTerrain(new NetherTerrainGenerator()).setSkyColour(RED) and had it all ready to go.

Answer 4

There's a lot of airy claims like "they can't be reasoned about".

Virtually any application will in fact have a few globals, they just get dressed up as singletons, as context objects that get passed around willy-nilly, or as back-tracking links in an object hierarchy. Modern languages have lots of facilities to avoid putting variables formally into the global scope, yet nevertheless allowing them to be accessed from anywhere.

And all programs have an irreducible minimum of data that must flow across the widest scope - if no such flow existed, then it would be possible to divide the program into two separate programs without any loss of function (and after which, variables which previously seemed to be local, would now be global to the whole program).

The problem with globals arises when they are used to compensate for (or enable) a lack of program structure, or when the globals themselves become a menagerie of unorganised variables. It's under these conditions that globals become part of a program that is impossible to reason about.

Answer 5

Sometimes it's about what you make me read.

When I'm debugging something that relies on a mutable global variable (sorry, depends on) you force me to go read anything that writes to it to understand how my code behaves. That's not fun.

Sometimes it's about moving the code.

When I'm moving code somewhere else I don't want it to know about the world around it because I'm changing that. Anything that makes it aware of the outside now has to be edited. Anything edited has to be retested. That's not fun.

Sometimes it's about testing the code.

When I'm testing code I need to control everything that it depends on to demonstrate what it does under different conditions. Stick me with a global and I have to manipulate it. Since other things likely know about it (cause it's, ya know, global) I now have to ensure none of them is going to break in anyway that I care about.

Sometimes it's about magic.

Sometimes I just don't know what's going on. Even after all these years. Seriously. And when I'm in that head space I just don't need this, "oh and one more thing", to think about. Enough! I want to squeeze all the magic out of the code and make it easy to predict. Globals just have too much pixie dust on them.

That's what we mean by "reason about it". I like code that lives a simple life. Full of short stories. That can stick to one page.