8 ms·

I'll play the devil's advocate. Global (shared) variables are fine when they represent non-instantiable program state and have descriptive names, with a clear s

I'll play the devil's advocate. Global (shared) variables are fine when they represent non-instantiable program state and have descriptive names, with a clear semantic contract for mutating their state. Essentially, something like `the_world.rotation_speed` is a good example.

mpartel 8y ago
What if you, one day, want multiple worlds for some reason? I'm developing a game in Unity, and the programming culture around it encourages globals and singletons to an unhealthy degree. I pushed back against them heavily in our project. As a result, it was very easy to add a previously unplanned split-screen mode one day, thanks to the codebase (e.g. the UI and input modules) not assuming that there's only ever one local player.
- bluetomcat 8y ago
  In the basic case when you don't need to clone the world, you avoid the passing down on the call stack of what is truly a global variable, disguised as a local instance. As a casual reader of such code, you might be deluded that `the_world` in `func1` is something different from `the_world` in `func2`, when they are the same. If you plan to "virtualise" stuff later, instantiation is certainly the way.
  - mpartel 8y ago
    I'd rather readers of such code take the (IMO minor) extra effort to consider the possibility of the worlds being different rather than bake the assumption that they're the same into even more code. That's how globals spread around your codebase, little by little, until it's very hard to refactor away from them. Better to just say no from the start. Also, if you have so many globals that passing them around as parameters / instance variables becomes truly tedious, that can be a valuable signal that the program is poorly structured. Of course, none of this matters in small codebases, as long as they stay small.
- JimDabell 8y ago
  > What if you, one day, want multiple worlds for some reason? Write code for the application you want, not the set of all applications you might hypothetically want someday. Incur the cost of new features after you decide you want them, not before.
  - mpartel 8y ago
    In general I fully agree, YAGNI and all that, but from experience, mutable globals, unless used very sparingly, rigidify the codebase to a surprising degree and make it more error-prone, often for very little actual gain. As with any software engineering guideline, there are exceptions. E.g. Java-style loggers are so ubiqitous and "not that mutable", that it's generally good for them to be global. Edit: also from experience, suddenly wanting two of something where before there was only one, is not that uncommon.
  - AstralStorm 8y ago
    Global state is a maintenance cost from day 1, increasing over time.
darekkay 8y ago
This is how Redux (Flux implementation) in JavaScript works. Basically the whole application state is maintained in a single, global variable. Also, every possible action has a global string ID constant. Coming from Java and its best practices it seemed really odd at first, but it makes state management and debugging so much easier.
rypskar 8y ago
>`the_world.rotation_speed` Isn't properties for the globe by definition global? Also, in most cases, would not the rotation speed of a world be a constant not a variable?

mpartel 8y ago

What if you, one day, want multiple worlds for some reason? I'm developing a game in Unity, and the programming culture around it encourages globals and singletons to an unhealthy degree. I pushed back against them heavily in our project. As a result, it was very easy to add a previously unplanned split-screen mode one day, thanks to the codebase (e.g. the UI and input modules) not assuming that there's only ever one local player.

bluetomcat 8y ago
In the basic case when you don't need to clone the world, you avoid the passing down on the call stack of what is truly a global variable, disguised as a local instance. As a casual reader of such code, you might be deluded that `the_world` in `func1` is something different from `the_world` in `func2`, when they are the same. If you plan to "virtualise" stuff later, instantiation is certainly the way.
- mpartel 8y ago
  I'd rather readers of such code take the (IMO minor) extra effort to consider the possibility of the worlds being different rather than bake the assumption that they're the same into even more code. That's how globals spread around your codebase, little by little, until it's very hard to refactor away from them. Better to just say no from the start. Also, if you have so many globals that passing them around as parameters / instance variables becomes truly tedious, that can be a valuable signal that the program is poorly structured. Of course, none of this matters in small codebases, as long as they stay small.
JimDabell 8y ago
> What if you, one day, want multiple worlds for some reason? Write code for the application you want, not the set of all applications you might hypothetically want someday. Incur the cost of new features after you decide you want them, not before.
- mpartel 8y ago
  In general I fully agree, YAGNI and all that, but from experience, mutable globals, unless used very sparingly, rigidify the codebase to a surprising degree and make it more error-prone, often for very little actual gain. As with any software engineering guideline, there are exceptions. E.g. Java-style loggers are so ubiqitous and "not that mutable", that it's generally good for them to be global. Edit: also from experience, suddenly wanting two of something where before there was only one, is not that uncommon.
- AstralStorm 8y ago
  Global state is a maintenance cost from day 1, increasing over time.

darekkay 8y ago

This is how Redux (Flux implementation) in JavaScript works. Basically the whole application state is maintained in a single, global variable. Also, every possible action has a global string ID constant. Coming from Java and its best practices it seemed really odd at first, but it makes state management and debugging so much easier.

rypskar 8y ago

>`the_world.rotation_speed` Isn't properties for the globe by definition global? Also, in most cases, would not the rotation speed of a world be a constant not a variable?