Using all global variables?
Author
Is using all global variables in my programs a bad practice? It helps me keep track of things easier then having local variables and passing them back and forth.
Many people will say its a bad thing since you can easily change them on accident but if you are going for speed over anything, ie programming games, and you can keep track of anything, using globals is better in my opinion, although if you are writing something like an SDK then using globals is clearly a no no since other people wont know exactly what you named your variables in the function.
I as well utilize global variables for everything but sometimes I become confused what I am utilizing variables for. If I have the variables localized to something, then I know what that is used for and I won't be able to use that variable for something that I will be in trouble for later.
For example, if I create a global variable called "loop" and used it for all my "for" statements, there is a chance I will have a "for" statement that will execute a function that utilizes the "loop" variable for its own purposes. This will create a headache since instead of the problem being localized to a single part of the application, it might be spread out.
Though, having not type in and return data from my functions is a good things as well since I do not have to fiddle around with passing data in/out of the function.
It mainly will depend on you but if another person were to work on your code, they might not like it at all - even with development documents to look at.
For example, if I create a global variable called "loop" and used it for all my "for" statements, there is a chance I will have a "for" statement that will execute a function that utilizes the "loop" variable for its own purposes. This will create a headache since instead of the problem being localized to a single part of the application, it might be spread out.
Though, having not type in and return data from my functions is a good things as well since I do not have to fiddle around with passing data in/out of the function.
It mainly will depend on you but if another person were to work on your code, they might not like it at all - even with development documents to look at.
I think globals don't help in keeping the code reusable. It's best to put them in their relevant classes (design design!). You could also wrap a global in a singleton. Typical example is a shared logger instance. Also, globals aren't thread safe so you may have to deal with that. If you must use globals then make them static so they're hidden in the compilation unit.
Globals are crap.
Seriously, how many variables in your game really need to be global? The same arguments against singletons typically apply to global variables as well.
Does the sound system need to know the game score? Does the rendering system need to know the direction the wind is blowing? Does the input system need access to the Direct3D device pointer? I would think not.
Generally, globals are signals of bad design, and really should be avoided with large projects.
They kill modularity. They also make you really tempted to actually reference the wind direction in the rendering code, which would kill reusability.
In short, try to avoid them. This doesn't mean you need to go OOP to the extreme -- you can still do multi-paradigm programming. Just don't keep all that stuff in the global namespace, because it almost definately doesn't need to be there.
Seriously, how many variables in your game really need to be global? The same arguments against singletons typically apply to global variables as well.
Does the sound system need to know the game score? Does the rendering system need to know the direction the wind is blowing? Does the input system need access to the Direct3D device pointer? I would think not.
Generally, globals are signals of bad design, and really should be avoided with large projects.
They kill modularity. They also make you really tempted to actually reference the wind direction in the rendering code, which would kill reusability.
In short, try to avoid them. This doesn't mean you need to go OOP to the extreme -- you can still do multi-paradigm programming. Just don't keep all that stuff in the global namespace, because it almost definately doesn't need to be there.
Quote:Original post by DRPhil
Down with global variables. Up with accessor methods.
Down with accessor methods. Up with properly encapsulated code which shouldn't need accessors in the first place because the object's methods define *operations* on the object rather than exposing the data for other functions to manipulate.
Quote:
...if you are going for speed over anything, ie programming games, and you can keep track of anything, using globals is better in my opinion...
Premature optimization aside, this may well be wrong. The big reason that comes immediately to mind is your cache. Anything that saves passing a parameter will cost you in terms of cache misses. You also destroy the compiler's ability to perform otherwise trivial optimizations. So you have a questionable optimization coupled with a design that'll hurt in the long run.
Some globals are OK in a 'who cares' sort of sense. You probably won't mind if you have a single Game object that holds passes parameters, for instance. But creating a global enemy object rather than passing an enemy parameter is probably trouble.
CM
If you can be organized with your code, globals are better because they increase application speed.
While I dont think globals are crap, there is after all a place for everything, I dont see a signifigant speed advantage in having all globals, the time it takes to declare a variable on the stack... is marginal, and considering the raw processing power most computers possess today anyways, who cares about that extra nanosecond or two?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
