When is it ok to use a global variable in C?

Apparently there's a lot of variety in opinions out there, ranging from, "Never! Always encapsulate (even if it's with a mere macro!)" to "It's no big deal - use them when it's more convenient than not."

So.

Specific, concrete reasons (preferably with an example)

• Why global variables are dangerous
• When global variables should be used in place of alternatives
• What alternatives exist for those that are tempted to use global variables inappropriately

While this is subjective, I will pick one answer (that to me best represents the love/hate relationship every developer should have with globals) and the community will vote theirs to just below.

I believe it's important for newbies to have this sort of reference, but please don't clutter it up if another answer exists that's substantially similar to yours - add a comment or edit someone else's answer.

-Adam

Variables should always have a smaller scope possible. The argument behind that is that every time you increase the scope, you have more code that potentially modifies the variable, thus more complexity is induced in the solution.

It is thus clear that avoiding using global variables is preferred if the design and implementation naturally allow that. Due to this, I prefer not to use global variables unless they are really needed.

I can not agree with the 'never' statement either. Like any other concept, global variables are something that should be used only when needed. I would rather use global variables than using some artificial constructs (like passing pointers around), which would only mask the real intent.

Some good examples where global variables are used are singleton pattern implementations or register access in embedded systems.

On how to actually detect excessive usages of global variables: inspection, inspection, inspection. Whenever I see a global variable I have to ask myself: Is that REALLY needed at a global scope?

The only way you can make global variables work is to give them names that assure they're unique.

That name usually has a prefix associated some some "module" or collection of functions for which the global variable is particularly focused or meaningful.

This means that the variable "belongs" to those functions -- it's part of them. Indeed, the global can usually be "wrapped" with a little function that goes along with the other functions -- in the same .h file same name prefix.

Bonus.

When you do that, suddenly, it isn't really global any more. It's now part of some module of related functions.

This can always be done. With a little thinking every formerly global variable can be assigned to some collection of functions, allocated to a specific .h file, and isolated with functions that allow you to change the variable without breaking anything.

Rather than say "never use global variables", you can say "assign the global variable's responsibilities to some module where it makes the most sense."

Consider this koan: "if the scope is narrow enough, everything is global".

It is still very possible in this age to need to write a very quick utility program to do a one-time job.

In such cases, the energy required to create safe access to variables is greater than the energy saved by debugging problems in such a small utility.

This is the only case I can think of offhand where global variables are wise, and it is relatively rare. Useful, novel programs so small they can be held completely within the brain's short-term memory are increasingly infrequent, but they still exist.

In fact, I could boldly claim that if the program is not this small, then global variables should be illegal.

• If the variable will never change, then it is a constant, not a variable.
• If the variable requires universal access, then two subroutines should exist for getting and setting it, and they should be synchronized.
• If the program starts small, and might be larger later, then code as if the program is large today, and abolish global variables. Not all programs will grow! (Although of course, that assumes the programmer is willing to throw away code at times.)