A Senior Developer's Guide to Naming Global Variables

Level 1: The Toy Everyone Can Grab

Imagine a classroom with one shared pencil case in the middle of the room that any kid can rummage through at any time, no questions asked. Your homework keeps going wrong because someone keeps swapping your pencil for a crayon — but with thirty kids who all have access, you'll never know who. A global variable is that pencil case: one thing the whole program can secretly change. Someone asks, "What's the best label to put on the shared pencil case?" and the joke answer is: a label that makes the pencil case disappear entirely. It's funny because instead of suggesting a better name tag, the answer says the thing is so troublesome that the only winning move is not to have it at all.

Level 2: Prefixes, Comments, and Why Globals Scare People

Three concepts collide in this one-liner:

• A global variable is declared outside any function and is visible everywhere in the program. Anything, anywhere, can change it — which is exactly the problem.
• A prefix naming convention is a habit of starting variable names with markers that signal what they are. In many older codebases, globals get a g_ prefix (g_userCount) so readers instantly know "careful — shared state."
• // is the line comment marker in C, C++, Java, JavaScript, and friends. Anything after // is ignored by the compiler — the code ceases to exist as far as the machine is concerned.

So the punchline, written out:

g_retryCount = 3;     // a global with a respectable prefix
// retryCount = 3;    // the "best practice" version: it's gone

Why the hostility? Picture your first week debugging a function that returns the wrong total. You read the function — it's fine. The bug turns out to be a global counter that a completely different file resets under certain conditions. Nothing in the function told you to look there; with a global, the whole codebase is the crime scene. The grown-up alternatives you'll learn are passing values as parameters, returning results, or injecting dependencies explicitly — all ways of making a function's inputs visible in its signature instead of hidden in shared state. That's a large part of what people mean by clean code: code whose behavior you can predict by reading just the part in front of you.

Level 3: The Only Prefix That Survives Code Review

Q: What is the best prefix for global variables? A: //

Richard (@zzaaho) compresses roughly forty years of software engineering doctrine into a setup and a two-character punchline, and the craft is in the misdirection. The question is phrased as a naming convention question — the kind of earnest bikeshedding that fills style-guide meetings. Should globals be g_count? gCount? G_COUNT screaming in caps? Hungarian-notation veterans will remember entire wars fought over these prefixes; the g_ convention exists precisely because globals are dangerous enough that codebases wanted them to look radioactive at a glance. The answer accepts the question's framing and then detonates it: the best prefix is // — the comment delimiter — because the best global variable is one that doesn't execute at all.

The reason this gets 209 retweets from people who've shipped software: mutable global state is the closest thing programming has to a consensus villain. A global is readable and writable from anywhere, which means every function in the codebase is a suspect when its value goes wrong. It creates spooky action at a distance — module A breaks because module Z mutated shared state — and it quietly destroys the three things maintainable systems depend on. Testability: tests stop being isolated when they share ambient state, producing the dreaded "passes alone, fails in the suite" lottery. Concurrency: two threads writing one global without locks is a data race, the kind of bug that appears only under production load at 3 AM and vanishes when you attach a debugger. Reasoning: a function signature that doesn't mention the global is lying about its inputs.

The deeper satire is about how the industry manages known-bad patterns instead of eliminating them. We invented naming conventions (g_), linter rules, style-guide chapters, and dependency-injection frameworks — an entire compliance bureaucracy around a feature everyone agrees shouldn't be touched. The tweet's answer is the radical simplification consultants get paid six figures for: instead of labeling the hazard, remove it. It's the same energy as answering "what's the best way to document this 400-line function?" with "delete it." And of course there's the self-aware irony that // is itself the laziest deletion mechanism we have — commented-out code haunting a codebase is its own code smell, so the joke's prescription is the one vice every reviewer tolerates more than a global.