Sign in to follow this  

Searching for a good article or discussion on globals (and how to avoid them)

This topic is 3631 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

My work is going to have a design meeting soon, and I wanted to talk about our unnecessary dependency on globals. Rather than trying to formulate my own speech or email, I thought I would find a good article to give them, written by a person more qualified than myself. I've been google-ing for a while, but I've been unable to find a good article or discussion on why globals are generally a symptom of bad design, and more importantly, how to design your software so that it doesn't need them. If you guys could point me to one or a good place to find one, I would be very grateful. Thanks, -Chris

Share this post


Link to post
Share on other sites
This is the best I can find, however it doesn't present well because it is far from clear. Maybe you could synthesise a speech from some of the points though.

It is a pity, these kind of things are one of the hardest to explain. It has to be experienced really. A program with many globals becomes unmaintainable. I *know* this, not because I was told by someone but because I had a project collapse due to this.

You can't really give an example because what makes them bad only comes from trying to add to or change a large codebase with many globals.

I think the best argument on the page is actually nowhere near the top:
Quote:

Once you have a global variable, it's much harder to get rid of it as time goes on.


All the other arguments are reasons why one would want to remove them.

Nowadays you'll find far more on arguments against Singletons, the "new, trendy global". But not as convincing because such arguments don't directly address global variables. Again though you may be able to take some of the points and use them in a condensed form.

I am curious, I find it hard to believe that there is a collection of programmers who need convincing that globals are supposed to be evil. Are you sure they all aren't like you (secretly (I assume) unhappy with the situation but plodding along because they think everyone else doesn't care)?

Share this post


Link to post
Share on other sites
Before bringing up a very messy topic: Are you sure you have an audience for it, and resources to change it?

Do you have power to enforce it? Mandate it? Teach it?

Unless the team is already aware of problems with globals, and perceives them as a barrier to current development, this is usually the type of topic that doesn't end well, and developers merely do ad-hoc "new and improved no globals ever with brand new singleton containers" type of solution.

Quote:
Rather than trying to formulate my own speech or email, I thought I would find a good article to give them, written by a person more qualified than myself


This makes it sound like you heard globals are bad and you want to be trendy and change it.

Are you sure globals are bad in *your* project? Can you quantify it? How many improvements can you present? How much will they cost? Who in your team will oppose it, who will fight it? Who will be quiet, and simply grumble and try to circumvent the rules. How will changing coding policy affect everyone, what impact will it have on productivity?

This may seem like irrelevant questions, but unless globals are killing your project - literally - and preventing you from completing objectives, then they are just a cosmetic thing. Unless there's some long-term strategy to develop the project, then it's a wasted expense.

Then again, I don't know what kind of project you're in, what kind of costs or investments we're talking. But if you feel that this will improve the project and development, then you'll have to be prepared to defend your claims not with some random article that nobody will care about, but with actual examples on your very codebase.

Globals and similar disasters are not a technological problem - you're fighting culture, and that can end really badly, unless you can present full strategy for change.

If you're a manager or have authority, then you can simply mandate it, allocate the time for it, and be done with it.

If you're not, and you wouldn't violate corporate policy, then simply refuse to use them, and provide non-globals based design in your code. If it works well, others will adopt it, and then you get leverage for refactoring old code.

Meetings alone however rarely produce any results, especially if no stakes are involved and they merely involve culture.

Share this post


Link to post
Share on other sites
Thanks for the info. I'll check out those articles and see if they help.

My coworkers are expressing the typical "globals are bad, but their convenience outweighs their negative impact", and "it's too hard not to use globals".

Their dependence on globals isn't overwhelmingly bad or anything, but any dependence could be considered bad.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Before bringing up a very messy topic: Are you sure you have an audience for it, and resources to change it?

Do you have power to enforce it? Mandate it? Teach it?

Unless the team is already aware of problems with globals, and perceives them as a barrier to current development, this is usually the type of topic that doesn't end well, and developers merely do ad-hoc "new and improved no globals ever with brand new singleton containers" type of solution.

Quote:
Rather than trying to formulate my own speech or email, I thought I would find a good article to give them, written by a person more qualified than myself


This makes it sound like you heard globals are bad and you want to be trendy and change it.

Are you sure globals are bad in *your* project? Can you quantify it? How many improvements can you present? How much will they cost? Who in your team will oppose it, who will fight it? Who will be quiet, and simply grumble and try to circumvent the rules. How will changing coding policy affect everyone, what impact will it have on productivity?

This may seem like irrelevant questions, but unless globals are killing your project - literally - and preventing you from completing objectives, then they are just a cosmetic thing. Unless there's some long-term strategy to develop the project, then it's a wasted expense.

Then again, I don't know what kind of project you're in, what kind of costs or investments we're talking. But if you feel that this will improve the project and development, then you'll have to be prepared to defend your claims not with some random article that nobody will care about, but with actual examples on your very codebase.

Globals and similar disasters are not a technological problem - you're fighting culture, and that can end really badly, unless you can present full strategy for change.

If you're a manager or have authority, then you can simply mandate it, allocate the time for it, and be done with it.

If you're not, and you wouldn't violate corporate policy, then simply refuse to use them, and provide non-globals based design in your code. If it works well, others will adopt it, and then you get leverage for refactoring old code.

Meetings alone however rarely produce any results, especially if no stakes are involved and they merely involve culture.


The project we're working on is in the early design/implementation stages. I was putting in a new high-level component, and when asking where to put it, everyone answered "make it a global".

I simply wanted to voice my concern with making globals the default solution to this kind of problem, especially since this new component doesn't need to be accessed by every subsystem.

They company is pretty small and far from the corporate setting. We have these kind of discussions fairly often.

My problem with globals in this project is actually compounded by other design problems that happen to rely on them, but, of course, the topic of globals by itself is more prone to debate.

[Edited by - extralongpants on January 7, 2008 5:57:10 PM]

Share this post


Link to post
Share on other sites
Well, the meeting has ended, and, not surprisingly, I failed to convince anyone of anything. [sad]

There was one fellow programmer at the meeting who agreed with me, and understood what I was trying to say, but he urged me to give up (as he has), because trying to convince the rest of the programmers was futile (or something to that affect).

The conversation died after that.

It was worth a try, I guess [smile]

I'm sure there are many more meetings to be had, and the subject may come up again. Maybe I can whittle them down over time [evil].

Share this post


Link to post
Share on other sites
Many of problems with singletons apply to globals as well. In my mind, the biggest problem with globals (as raw globals or singletons) and getting rid of them is twofold.

The concrete problem is that because they are globally accessible it becomes extremely easy to use them anywhere, anytime, without thinking, which can quickly introduce a tangled spaghetti web of interdependancies and coupling.

The related problem is that many programmers are attached to their code on an emotional level, and haven't come to grips with the fact that they write bad code. The very idea that they might do something wrong, or that they might not think about what they're doing, is just impossible for them. Other programmers write bad code, I write great code.

As a result, most people don't think globals are a problem because they assume they'll never misuse them, nevermind that that is an extremely arrogant and ultimately short-sighted view.

As for avoiding them, the solution is simple: stop using them, pass what you need to where you need it, and if that becomes unweildy, consider that your higher-level design may be flawed and in need of refactoring to remove dependancies. Remember that it's ultimately the dependancies and the coupling that are the problems -- not globals. Globals are problematic because they are extremely easy to use to create more dependancies and coupling problems (and what is easy to use will be used). A constructor taking 22 arguments is ugly -- which is good, it's the code telling you that something is rather wrong here. A constructor taking zero arguments but using 22 globals is has all the same problems, with the additional problem that those 22 dependancies and coupled classes aren't nearly as easy to notice.

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
Many of problems with singletons apply to globals as well. In my mind, the biggest problem with globals (as raw globals or singletons) and getting rid of them is twofold.

The concrete problem is that because they are globally accessible it becomes extremely easy to use them anywhere, anytime, without thinking, which can quickly introduce a tangled spaghetti web of interdependancies and coupling.

The related problem is that many programmers are attached to their code on an emotional level, and haven't come to grips with the fact that they write bad code. The very idea that they might do something wrong, or that they might not think about what they're doing, is just impossible for them. Other programmers write bad code, I write great code.

As a result, most people don't think globals are a problem because they assume they'll never misuse them, nevermind that that is an extremely arrogant and ultimately short-sighted view.

As for avoiding them, the solution is simple: stop using them, pass what you need to where you need it, and if that becomes unweildy, consider that your higher-level design may be flawed and in need of refactoring to remove dependancies. Remember that it's ultimately the dependancies and the coupling that are the problems -- not globals. Globals are problematic because they are extremely easy to use to create more dependancies and coupling problems (and what is easy to use will be used). A constructor taking 22 arguments is ugly -- which is good, it's the code telling you that something is rather wrong here. A constructor taking zero arguments but using 22 globals is has all the same problems, with the additional problem that those 22 dependancies and coupled classes aren't nearly as easy to notice.

Thanks for the information. Now that you mention it, I think it was that very singleton article (and maybe one or two more) that I was thinking of all along. It addresses almost all of the same problems.

In response to Antheus's concern:
I used to be that guy that you alluded to - the one that avoids globals and preaches the same to others, simply because I'd read once that "globals are evil".

It wasn't until I had to work on a BREW application that I realized why.

Because you are not allowed any global or static data in BREW, you must write your entire application without the use of a single global [wow].

At first it was a struggle for me, and I felt that I was unnecessarily inconvenienced. By the time the project ended, however, I grew to love my global-less code. It was then that I gained a real understanding of the benefits of removing globals (and other similar constructs) from your code.

Brings a tear t' yer eye, don' it? [bawling]

Share this post


Link to post
Share on other sites
Quote:

Aren't static member variables the solution to globals? just wondering.

No, they're no different.

How would static members "solve" any of the above problems? The differences between

MyGlobal->DoSomething();
MySingleton::GetInstance()->DoSomething();
MyClass::Instance->DoSomething();

are superficial. The same underlying dangers exist.

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
Quote:

Aren't static member variables the solution to globals? just wondering.

No, they're no different.


Exactly, but static member variables at least aren't exactly orphans, no need to redeclare them as extern in whatever source file you need access to them, and they move along with the class definition in case of code reuse.

I guess its a matter of practical evilness vs technical evilness? usability vs concept?

Share this post


Link to post
Share on other sites
Quote:
Original post by Kwizatz
Quote:
Original post by jpetrie
Quote:

Aren't static member variables the solution to globals? just wondering.

No, they're no different.


Exactly, but static member variables at least aren't exactly orphans, no need to redeclare them as extern in whatever source file you need access to them, and they move along with the class definition in case of code reuse.

I guess its a matter of practical evilness vs technical evilness? usability vs concept?


No, it just means you might save some typing while implementing the spaghetti.

Share this post


Link to post
Share on other sites
Quote:

Exactly, but static member variables at least aren't exactly orphans, no need to redeclare them as extern in whatever source file you need access to them, and they move along with the class definition in case of code reuse.

I guess its a matter of practical evilness vs technical evilness? usability vs concept?

No. They're just not solutions. Who cares if they move with the class, or are "orphans" -- what's an orphan? A static variable is basically a global in a namespace, plus some other language-related fluff and constraint, nothing special. They have the same problems. If static variables exhibit the same deep-rooted problem that globals have, how can you consider them a "solution" in any sense of the word?

They just have slightly different implementation flavor.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kwizatz
Quote:
Original post by jpetrie
Quote:

Aren't static member variables the solution to globals? just wondering.

No, they're no different.


Exactly, but static member variables at least aren't exactly orphans, no need to redeclare them as extern in whatever source file you need access to them, and they move along with the class definition in case of code reuse.

I guess its a matter of practical evilness vs technical evilness? usability vs concept?

Those differences are all trivial though. The real problems (as stated above) are dependancies and coupling and a static member variable isn't any different.

Static variables within a function, however, can be significantly different. But they come with their own set of problems.

Share this post


Link to post
Share on other sites

This topic is 3631 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this