2

Well here I am sitting down for the millionth time telling myself "I'm going to write a game using SDL and C++" except this time I told myself I was going to write it in C. This is because SDL itself is written in C and it seems to just make sense to me. The game that I'm writing will be a simple "SHMUP" (Shoot 'em up) and it will probably be very short code-wise, so I'm wondering are a couple global variables bad? (like "struct base basevar;" or "int SCREEN_W" or something)?

John Kugelman
  • 349,597
  • 67
  • 533
  • 578
Lemmons
  • 1,738
  • 4
  • 23
  • 33
  • Recent and almost identical question: http://stackoverflow.com/questions/4101856/global-variables-again/4102136#4102136. The answer is probably "yes" BTW. See also http://www.eetimes.com/discussion/break-point/4025723/A-pox-on-globals. – Clifford Nov 06 '10 at 22:25

5 Answers5

4

Global variables aren't inherently "bad". However, they can easily lead to very bad code (in the sense of readability, testability, maintainability) if used carelessly. They can also lead to pernicious multi-threading issues (if you're using threads), again, if used carelessly.

Some people have a blanket rule that you should never use them. IMHO, this is too draconian, and if followed religiously, can lead to people passing around a pointer to a big everything_t to all functions, which isn't a great deal better (although even this simple approach makes your code re-entrant). However, please don't read this as advocation for "just go wild with globals!". They are the right answer only in a few situations.

In your example, it sounds like you have a bunch of settings/parameters that don't really change. Consider at least grouping them into a settings struct; this gives you the flexibility later to have e.g. a const settings *getSettings() function.

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
  • Kind of, my original intention was to simply have global structure variables. You know: struct blahstruct structvarforblah; – Lemmons Nov 06 '10 at 21:03
  • 1
    +1 for some sense of balance. I'm writing a simple MUD server in C, and the nature of this problem means that there is global data. I could spend ages passing an extra `struct Mud *` parameter around, but let's be realistic. Global variables have language support for a reason. – Jack Kelly Nov 06 '10 at 21:07
  • 1
    @Jack Kelly: I'm in a similar situation. Context data is stored in TLS at entry and removed at exit from my library functions, making my code base reentrant for "free". – Matt Joiner Nov 07 '10 at 07:08
1

Well, let's consider why globals are considered bad. It's their unconstrained visibility. Global variables are accessible to all code, for reads and modifications. A design based on proliferation of globals, defeats structure. The reads and writes can come from anywhere. And while this may be OK when you first implement something (because you know the land), it can be catastrophic because of the kind of code it encourages. Soon you end up with a spaghetti of relationships and interactions.

Having said this, a blind hatred of globals is also not warranted. I mean, globalness can be relative. A class name is global within a namespace. A class member is global within the namespace established by the class. So, if the codebase for a class becomes large enough, the same argument made against globals, can likely be made against class members. In fact, namespaces and classes are, in part, mechanisms to contain this disease of globalness. They are (in part) mechanisms to draw boundaries of visibility and access.

So, in my view, globalness is not the issue. It's really about how it affects structure.

Ziffusion
  • 8,779
  • 4
  • 29
  • 57
0

While probably not deadly in this situation, you don't know what you'll want to do with your code in the future. If the game gets bigger, global variable will make debugging hard. If you decide to re-use the code for another game or even for something drawing 2 screens at once, the globals will get in the way.

You should practice good programming style even when it doesn't matter so you'll get it right when it does.

Steve Rowe
  • 19,411
  • 9
  • 51
  • 82
0

It depends on whether or not you plan on re-using the code. If you ever plan on changing the code into anything else, ever, then do not use a global, because they're incredibly hard to factor out.

Puppy
  • 144,682
  • 38
  • 256
  • 465
0

It could also be good to know that some environments, specifically old versions of Symbian doesn't support global variables, or even static locals.

onemasse
  • 6,514
  • 8
  • 32
  • 37