• Advertisement
Sign in to follow this  

Use Of Static Variables

This topic is 628 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

From what I've read, the consensus seems to be to avoid using static variables if at all possible. Why?

 

It seems to me that use of statics can help to reduce cluttered code by removing certain kinds of parameterisation. For example, in my code my main class has a 

public static Assets assets;

 object to manage my assets and a 

public static float elapsedTime;

variable to track the total time that has passed, which is necessary for things like animations to work. By making them static, I can simply call them in the classes that need them without having to pass them by parameter. Why is this considered bad practice?

 

 

Share this post


Link to post
Share on other sites
Advertisement
When something is global, it is easy to be accessing it in parts of the program that really shouldn't. For example, you may add some bit of code in a pathfinding algorithm that handle globals dealing with how sound works. You then try to reuse your sound code without the pathfinding and it doesn't work the same, or you reuse the pathfinding and it starts randomly playing sounds.

When using globals, the behavior of your classes no only depend on their internal values, but possibly the entire global state of the program. Often when programs are simple, globals aren't that bad but as your program grows they become a big pain.

I have found in my own projects when I have used globals, singletons included, it becomes difficult to maintain and add new features. When I remove global state, I come up with better program structure and code quality as a whole goes up.

Share this post


Link to post
Share on other sites

Thanks guys, you've convinced me.  :D I'll try to refactor statics out of my code and avoid them in the future.

Share this post


Link to post
Share on other sites

Thanks guys, you've convinced me.  :D I'll try to refactor statics out of my code and avoid them in the future.


A small amendment I always add to these discussions: things like this have problems, yes, but they also solve problems, too. Be careful of blindly applying rules or advice about code structure that aren't built around your project's specific needs. Understand why globals/statics are troublesome and then evaluate those concerns against your codebase.

Sometimes a global really is the best solution. Globals should probably be pretty rare but not necessarily verboten.

Share this post


Link to post
Share on other sites

Statics are less global than globals which is a pro. I don't know how things work in Java but in c++ I've seen statics use to good effect on objects that are expensive to make but relatively cheap to copy (when they all initialise the same). Also in c++ I think they can be well used as class/file constants since they can be type safe (compared to say #defs) and avoids having magic numbers in your code. 

Edited by Nanoha

Share this post


Link to post
Share on other sites
Statics are globals in disguise, and are usually a sign of a bad code smell, like someone deciding a value needs to persist beyond the lifetime of the containing object, instead of factoring it out to a separate object and managing it correctly.

I spend much of my time fixing or working around code that was broken as a result of someone choosing a global or a static to make their life easier when it clearly was the wrong thing to do. Don't be one of those people.

Share this post


Link to post
Share on other sites

Static members create exactly one of something and forbid creating another one.   This is an extremely rare pattern in programming.

 

That does not mean static items do not exist.  They are rare, but they exist.  It is almost always the wrong solution. But sometimes it is the right solution.

 

The biggest problem, already mentioned above, is mutability of state. Generally reading from a shared state is a tight coupling, it introduces hidden dependencies. But in some situations as long as you are only reading the state it can work out as a reasonable solution for a specific problem.

 

If the only reason you are using a static object is for convenience, it is the wrong answer to the problem.

Share this post


Link to post
Share on other sites

Statics are fine for singletons like a factory class or something, but i tend not to use them for variables at all -> There are always an entry point in every application!

When i find me in a situation when i pass too much parameters to a method i just use a "context pattern" and wrap this parameters into its own class/struct and pass this instead.

Example: UpdateGame(GameState *state) against UpdateGame(RenderState *renderState, MemoryState *Memory, InputState *state, ...)

 

But i use statics for method declarations all the time, because static has more meanings that just "global". Static in c++ can mean also "internal" - like "can be used in this unit only.

The first thing i do in C to declare a macros like this and use this instead of static directly (filtering is much easier this way):

 

#define internal_method static

#define global_variable static

#define local_persist static

 

Statics are also bad in other scenarios, like for example:

 

- Statics in a Server application (Except from factory instances) are bad when the scope/thread switches (Reloading a dll or something can cause this!)

- Multithreading/Parallel computation can go very wild with statics even with proper locking mechanism (GC decides to dispose static or something - will not happen in C...)

- Compiler may do nasty optimizations on static variables which may cause unforeseen consequences now or in the future

Edited by Finalspace

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement