A simple solution would be encapsulation.

You need to encapsulate certain logic in their (logical) classes. For example, all the rendering code should be encapsulated in the Renderer class. All data are to be private members of that class, which only the class itself can access.

Quote:Original post by Sc4Freak
My game code is filled with globals. [...] a whole bunch of globals that anyone can access.

Change the way of accessing that information:

Put the actual data in the class that manages it and let the rest of your app get the data only through the instance of that data manager class.

Quote:Original post by Julian90
You don't gain anything from making FormerGlobal a property as you can always change it later without having to change any code which uses it. It doesn't increase encapsulation and it leads to duplicated information which is bad.

It's a common convention not to use public class-level variables.

google "coding style" or "bad practices" and you should find info about why not to do it.


P.S.: I do as you say some times, but when trying to explain something, I try to use standard practices as much as I can.

Quote:
Zanshibumi: Why are you doing this: ....

I must agree with Julian here. Trivial properties (that just return or set the underlying field) in C# are a waste. Unlike C++, changing a field from public to private-but-exposed-via-a-property is trivial even without the powerful refactoring capabilities offered by most IDEs for C#, because in C# the change does not require a change at sites that use the public field, whereas in C++ it would (you'd have to add parentheses for the accessor call and potentially reshuffle the line). The arguments for trivial accessors in C++ are already pretty frail, but they fall down completely in C#.

Quote:
It's a common convention not to use public class-level variables.
google "coding style" or "bad practices" and you should find info about why not to do it.

It's a common C++ convention. I'm not arguing that encapsulation is bad, but a trivial property, a public pair of trivial set/get methods, and a public field are all equally "encapsulated" (that is to say, not at all). The rest is just implementation detail. The implementation detail makes for more work in C# and adds no benefit, whereas in might in C++ (using get/set methods does allow you to put constraints in later without changing client code, but that does not apply to C#).

Trivial properties are not good C# convention.





Of course, all of this is moot. The original poster isn't using C# (because he has global variables in namespaces). The notes about encapsulating all his globals does, of course, still apply.

I read about that a lot of time ago and decided to follow the standard in this case.

For whoever reads this, Here you have a much more detailed discussion about the same.

I decide what are good conventions or bad conventions for me when I make my own code. If it's for someone else, I try to stick to the standard. At work I just use the one imposed.

Quote:Original post by Kazgoroth

someobject.x = 1;someobject.y = 1;

Case 3

someObject.setX(1);someObject.setY(1);

So, where's the benefit of Case 3 as compared to Case 2 in terms of encapsulation?

Case 3 would be

someObject.X = 1;

too. (in C#)

Which means no benefit or loss, from outside the class.

However, the class internal storage of that information could change in the future without changing in any way the access from outside nor having to recompile.

In case3, if you release a dll and some people start using it in environments you can't interfere with. You can still change the way that information is stored inside the class (for example, X and Y in a Point structure, a file or a remote server) without modifying the external access to that information.

You could argue that the same could be done simply by having:

public int x;

and later changing it to:

public int x{   get {return GetVariableFromFile("x");}   set {SaveVariableintoFile("x", value);}}

However it could bring problems


Anyway, I just set it like that because that's how I've seen teachers usually put code; every standard followed (to the extent of my knowledge and lack of custom).
As you all seem to think it's simply wrong to use that way of coding in explanations, I'll stop using it.