A variable us something that varies, mutates, changes value, call it what you will. Global mutable state (i'd say, any non-local mutable state) complicates things and is a defect attractor.

Global constants are fine. Something like pi is as global as it gets, and it's never a problem.

There's an intermediate case of "global config info" which is technically mutable but is only mutated during a program startup, and stays constant during execution.

That is presuming they stay constant forever. Which generally only makes sense for mathematical constants and type bounds.

Otherwise it is better to pass them in (via dependency injection or otherwise) encapsulated so that enhancing the code for them to become variable or have versions is easy.

It's fine as long as the variables aren't mutable. Shared mutable state is the real killer.

I still have a hard time being dogmatic about this. For some simple multithreaded apps I'll use a global "STOP" variable, which I mutate when shutting down. All of the functions check this before attempting to gracefully exit.

I've done alternatives and I've never really seen the benefit.

The threads could take a pointer/reference to the "stop variable" and use the reference instead of accessing the global variable directly. That allows you to mitigate many problems of global variables. Sorry, if you already do this.

Honest question but what do I really gain in this scenario? Now all worker function arguments are N+1. I feel like it’s the waterbed affect and the complexity is simply pushed around elsewhere.

It seems like there’s simply a reasonable cognative “maximum” of global before it becomes unworkable. My gut tells me it’s between 1 and 4.

Gain? You could pass different pointers to each worker function, giving you a way to partially shutdown your process, or to shutdown some workers first, and workers they depend on later.

Of course, if you don’t need that, it’s not a gain, and a global is fine.

Globals also are fine if you are resource constrained (e.g. if you have a few kilobytes of RAM or even less) Getting your code running in it may trump everything else.

I think the main benefit is that every function relying on the stop variable is clearly defined as such, as opposed to having to find out manually who is reliant on it based on usage; its not so much moving complexit around as it is making things more explicit. im not sure how useful this is in practice though, for the common case

For one thing, you immediately make that function unit-testable.

Then you want to make a library out of it and are stuck with a single stop-domain.

Not bad but I always try to limit the scope of variables as much as possible. Makes reading the code easier.

The only (relatively minor) downsides I can see are:

(A) it makes the code "singleton" by default: you can't instantiate two objects of the same class with two different values for the global argument

(B) unless the global argument is declared in the same class, it slightly obfuscates the fact that a class depends on the argument (compared to all dependencies being constructor parameters)

(C) it makes testing, especially multithreaded testing, more awkward and error-prone: tests have to set and reset global variables

It's easy enough to refactor (A) where needed, as long as you have control of the code, and (C) can be worked around with good enough test helpers.

I think one can reasonably argue both for and against the convenience outweighing these downsides.

Perhaps they are minor if there's one or two global variables. Once they're used liberally and there's plenty of them, the resulting bugs can become so elusive it can drive you mad.

A bug can be extremely hard to replicate, because it only arises from a very specific sequence of events that step-by-step flip the globals into an overall invalid state. And it's virtually impossible to determine "whodunnit".

It's a perfect recipe for "the app sometimes crashes on Thursdays" scenario.

Ah, I meant to reply specifically to the command line flags use case.

For most other uses of globals, I fully agree.

Ah, then I misunderstood you, sorry.

Of course this is a bit of a red herring anyway... As the original commenter remarked already, command line flags may be stored globally (eg. as read-only fields), but won't - and shouldn't - be variables.

They're only given once, and their values aren't going to change throughout the program's running time. So they're essentially constants, which is fine.

I remember, in one of my earlier projects, we had code quality metric which used to run after each fortnightly build and integration. This tool used to count no. of global variables added to C and public variables added in C++ source code. Even if single such variable is reported, author of that code had to justify use of global/ public variables.

P.S. That doesn't mean there were no public/ global vars in legacy code. This practice started when code quality and system stability gradually started declining by their overuse

That honestly seems like a pretty good use case for global variables in a single entry point program.

Then those would be global constants not global variables.

Conceptually yes, but some languages don't have distinct constructs for constants and just use variables (sometimes even mutable) for everything.

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

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.