Theory Question: Global Variables

[BleaS]

I thank everyone for their input, and Paul, I do get it, which is why I'm motivated to follow the progression of learning that's been set out until I do classes. Until then I'll have to make do.

[andrey_zh]

Arrays seem a bit less complicated than learning classes.

Arrays are not a part of a *programming paradigm*. In simple words paradigm is a way of thinking. The paradigm you know in procedural programming. C++ supports many: procedural, object-oriented, generic, this I know maybe some more. You have to know arrays to deal with any modern programming language. By the way all the OOP could be imitated with means of procedural programming.

But I would like to continue our talk about global variables:

Here are Google coding standards (I've found them a long time ago and remembered about them now) and some quotes from them:
http://google-styleguide.googlecode....k/cppguide.xml

http://google-styleguide.googlecode....obal_Variables

Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction.

[BleaS]

Forbidden is a weighty word. They are allowed syntastically at least.

[jefranki]

andrey_zh was just quoting Google's in-house coding standards, which are about good coding practices (especially in a large team / multiple-programmer setting), not about what the language does or doesn't support.

[BleaS]

Ah. Well, I think that would make a bit more sense on a team. Where the reading suggests that global variables increase program complexity, adding more people to the project compounds that, no? Would it be safe to say that global variables would be a no on any large-team project?

[Speedo]

Remember too that Google's standards are written with Google's code in mind. They're useful as guides but you don't have to follow them verbatim. For example, they also forbid the use of exceptions, but clarify that that's mainly because their existing code isn't always exception-safe.

[nuzzle]

My question is: Is it common practice to see variables in a program that go in almost every function just so that they can be passed to other functions just because they are so relevant as a variable? That seems needlessly inefficient for variables that you know there is only ever going to be one instance of across an entire program.

Some variables are global by nature. What you can do is to define accessor functions to get and set the global variables instead of using them directly. This adds a thin layer of abstraction. In addition you should minimize calls to these global getter/setter functions. Use them only when absolutely necessary, for example to avoid passing a variable through unrelated sections of code to the place where it's actually being used as you mentionen, because this creates unwanted dependencies between program parts too.

Regardless of whether you use global setters/getters or a more advanced method of managing global state, like the Singleton design pattern, it's still global state; Too much of it will make your program more error-prone so use it with caution.

You can rarely avoid global state altogether in a large program. There's even an object oriented way to handle it called the Singleton design pattern (which ensures that a class only has one instance and provides a global point of access to it).

Unfortunately Singletons are often overused. Especially unexperienced programmes feel they've got a carte blanche to make extensive use of global data just because there's an established OO way to do it. The best advice still is to use global state with caution.