global variables are fine for things like config where you only change them from specific parts of the code but read them from many parts. there's really nothing specific that you can't do without them just that passing some information can get tedious. i feel like the whole "NO GLOBAL VARIABLES WHATSOEVER" comes from a pure object oriented design and i just never vibed with that. rigid rules are usually not a good idea.
this post was submitted on 06 Jul 2025
16 points (100.0% liked)
programming
255 readers
1 users here now
-
Post about programming, interesting repos, learning to program, etc. Let's try to keep free software posts in the c/libre comm unless the post is about the programming/is to the repo.
-
Do not doxx yourself by posting a repo that is yours and in any way leads to your personally identifying information. Use reports if necessary to alert mods to a potential doxxing.
-
Be kind, keep struggle sessions focused on the topic of programming.
founded 2 years ago
MODERATORS
Global constants make a lot of sense, those could be easily copied to where they need to go at compile time. The issue I’m having is that, if I allow global dynamic variables then it means having to allocate some sort of table or block for the global variables and if they can allocate more at runtime or even worse they try allocating strings or arrays at runtime memory will fragment and become a mess quickly
I will sometimes create a global caching object, but I typically program in Python, so having the cache allocated ahead of time isn't a big deal.
Even so I usually put a limit on the global cache unless I know exactly how big it's gonna be. I have a pretty large automation suite that requires tool scripts to be instantiated, and that initialization for each tool object can take up to 10 seconds. The system that runs the scripts is constantly creating and destroying the tool objects, so I had to cache them and hijack the init method to pull from a global cache or it would take up to a minute for the toolbox to load.
Since the initialized information (database connections and schema maps) is unlikely to change during a session, it was a good tradeoff.
As others said, global constants are totally fine. Especially for anything that requires authentication. I usually assign them on startup by pulling from either a config file or system environment variables.
Python also heavily relies on globals for logging, which is unavoidable if you want to use standard lib and also do logging.
Not a fan of them. Depends on the language I guess but if Im using a heavily object or functional language it feels dirty to stuff globals somewhere.
It feels like a sequential programming paradigm which just doesn't fit the structure of most languages I use nowadays.
I still like having my state clearly defined somewhere if necessary. Always declare them at the top of the main file and clearly document them if you need to use them though.
That can end up being painful for some use cases, because you then have to manage the lifecycle of that global state directly, and you risk weird bugs from mismanaging that state.
But that's from my perspective with application development, where your single point of truth is usually some remote database. You just end up with a bunch of ephemeral and persistent state that aren't intuitive when using a global state pattern.
That sort of pattern you describe is still pretty much ideal for other domains, IMO. Flutter/dart (my primary language) are just not suited it!
I use Python pretty heavily and global state there is pretty rock solid thanks to the GIL, I also work primarily on single system local programs where I don't have to worry about syncing anything over the network.
Fine for short scripts. Good to avoid for everything else and you should have a good reason to stray from the default if you’re gonna do so. No one instance of global state is a huge deal but it piles up quick as projects age.
Kinda yes. Dynamic extent globals, yeah those have some good uses. Indefinite extent globals? For a config variable or something that they have use, something that get set once, but read many times. That being said, i wouldnt miss them terribly i think 
Definitely ask yourself whether they really need to be, but using a global variable makes sense if it's something that's going to be used by a large number of different parts of the program.
For example, the game I'm developing uses a variable called control_mode to determine how to handle the player's button presses. Anything that can be affected by those button presses (the player avatar, the menus, etc.) needs to be able to know the game's current control mode to be able to handle user input, so e.g. the player character shouldn't be able to move during cutscenes or when the game is paused. Since so many different parts of the program need to read control_mode, I made it global, but I only change it from a dedicated control manager.
Messy at best and insecure at worst
They should exist. Some people code to be nerds and obsess over how clean and nice it looks, some people code to create things that won't be expanded on much and the readability and what not doesn't matter
I never needed any
did you need singletons or some other kind of "hidden" global?
Yes, but they were immutable