LOVE global variables, sometimes

March 29, 2024 •

I am a supporter of global variables being used in the correct context. I have found success using them in niche areas and advocate for their use in software development. Global variables can be problematic, and I understand why many people dislike them.

Global variables have led to split opinions on their utility in software engineering. They are beneficial but have been overused to the point of becoming abused, making them hated in the software engineering world.

Wikipedia describes a global variable as; a variable with a global scope, meaning it is visible (hence accessible) throughout the program unless shadowed. The set of all global variables is known as the global environment or global state.


Global variables are accessible from any part of a program. This gives them global scope, meaning that they aren’t limited to any particular function or code and are instead used throughout the entire program.

This means that one part of the program can change the global variable, causing issues or errors for other parts of the same program. This can cause fatal breaking points in the program. These are a commonly faced issue.

Global variables are exponentially difficult to debug after an error or failure because tracing the genesis problem is problematic, as it can be from any part of the program.

Maintaining the code with a lot global variables can be challenging as pinpointing which part of the program is responsible for altering the global variable is an incredibly difficult task.

Despite this, programmers still utilize global variables. It is easier to utilize, and reuse a global variable everywhere in the program. All this combined creates a problematic cocktail for programmers to handle.


There are two opposing schools of thought on the use of global variables. One side endorses the use of global variables without caring about the demerits. The other side opposes global variables, citing the aforementioned demerits.

My approach to programming does not fit any of these schools of thought. I often utilize global variables in my programming in a specific manner.

Productivity is the top and most obvious reason to use global variables. Global variables eliminate the need to pass the variables through functions, classes, and structs. My default position does not have me utilizing global variables, but utilizing them in specific instances has benefits.

This can be utilized in the logging system, as I don’t care much about it. It is significantly easier to use global variables, than to pass a log object to every place I would need it. This easily saves me tons of boilerplate code.

Another good example is utilizing global variables for the database connection, as every part of the application needs access to the database. Utilizing global variables in this manner might be the most unorthodox way to use them.


All examples above share a common theme. These are aspects that people aren’t supposed to change, but only use.

The logging and database, for instance, are classes that function without problems of race conditions. Some questions may arise on how I efficiently test my programs without having the option to dependency inject a database object. My solution to this obstacle is touse SQLite3 as a database. This way I avoid spending productive time on mockups or a fakes. Even more, I populate our testing environment with this fake data, and thus the QA and devs always know what objects/logins work and don't. This saves them time as well.

These steps have improved my and my teams' productivity immensely. I do have strict principles that almost nothing should be a global variable. As such, pull requests with new global variables are often rejected.