I know alot of people (my software design professor included) have this fervent hate for global variables, because they can cause side effects within functions that reference them, and violate the self-contained nature of modules. Now I am all for tight, self contained and self reliant modular programs, but in some instances I don't really see a way around the global issue. According to the aforementioned professor, anything that needs to be kept handy about environment variables should be passed in as parameters when needed and that way can help keep the function working only with specified inputs and produce only specified outputs. But what about the instance in which a set of functions operates based on the values of a number of state variables? Or, for a more concrete example--in my current project the initialization of the video, audio and input subsystems is dependent on values in the configuration file, which is read into a structure at program startup. This structure is also referenced in the options menu for proper updating prior to a program restart. What would be the alternative to making this structure globally avaiable and still making it accessible to five or six other completely seperate modules?

Le Singleton.

Then again, Singletons Are Evil.

It's true that global structures can be useful sometimes, but you want to work towards having minimal global data. This makes bugs more likely to happen and debugging difficult. If it's something like configuration settings, there's a good case for making it global. Other things can be passed in.

In C++, you can initialize everything by passing in parameters to a class constructor of the class that represents your module.

You appear to be using C or some other procedural language, so your approach might be different. Instead of storing a bunch of data in global variables, you can pass it to the function to use. This is easier for debugging, as you can more easily trace where what gets changed.

Instead of giving it gobs of parameters, put all the data in one or two convenient structures. The configuration, although it could be global, could be put in one structure and then passed as a parameter to any function that needs it. Drawing functions could receive a structure, which contains all the information about the screen, graphics, etc. that the function needs for drawing. A line function, for example, will receive a device context and coordinates as parameters. The coordinates tell it where to draw the line and everything else it needs is contained in the structure.

This, however, presents a problem: there is a lot of copying every time a structure is passed. This can be prevented by creating the structure somewhere and passing a pointer to the structure to every function that needs it. That will prevent inefficiency from copying.

That type of thing is good for data that isn't really global. Things like configuration settings usually apply for the entire application, and are really global data. You could perhaps provide functions that everyone uses to read or write the global data, but in C, it's difficult to prevent anyone from going directly to the data itself.

C++ is a bit nicer for this purpose because you can encapsulate and control access to data when you store it in a class.

I'm writing a game engine right now, and certain things such as the configuration manager and the log manager are available globally. Through encapsulation, however, I can prevent code from changing the configuration in ways I don't want.

I personally think that there are sometimes reasons for having global data, but it should be used very sparingly. It can be a big cause of headaches. I remember when I was first learning to program using QBasic, I didn't know about passing data as parameters, so I used global variables for absolutely everything that was going to be passed from one place to another. It was a terrible nightmare to maintain and debug. It was horrible to try to figure out where the variables were being changed and sometimes some code would stomp on the data of another piece of code. This was especially bad when I was using global variables in different places for different things. *This is a nightmare you want to avoid at all costs!* Any global data should mean the same thing to all the code everywhere in the program, and should be treated the same way by all code. In large projects, where you have different people with different understanding of the code, this becomes very difficult to ensure, and is a good reason why global data should be minimized.

Actually I'm using C++.

As for passing the configuration structure to every function to needs it, or a description of the screen setup to drawing functions; that seems so illogical to me. Writing an initialization function that accepts a config structure says to me that the function will be expected to operate on different configurations within one program instance; however there is in actuality only one configuration, as read from the game config file.

Oh well, my program design usually leans towards C at the lower levels, where (to me at least) class abstraction and all those neato features don't make as much sense, and then working into the engine becomes more classic C++ with a nice class hierarchy and inherently higher level code.

I'm still contemplating doing a depth-first trip through my source tree and straightening out a few frayed wires before moving on, to make things a little neater and acceptable to the outside world.