While you can "get away with" using variables with the 'static' modifier to make a "global variable" ... or define methods as 'static' to get a 'global method' ... I agree, strongly, with Philippe Mori that global variables are best expressed as properties in order to control their scope and use.
Why, you may ask, does one need to control scope and use ?
... Because use of global variables ... or methods ... is often a source of confusion in coding, and difficulty in development, code testing and maintenance, depending on the context of project development, the scenario of real-world use of the project ...
This brief example (.NET 4.0) demonstrates even "stricter" control of a global variable:
namespace GlobalVariables
{
public static class Globals
{
static Globals() { GlobalInt = 1234; }
public static int GlobalInt { get; private set; }
public static void SetGlobalInt(int newInt)
{
GlobalInt = newInt;
}
}
}
And, we'd use this example like so anywhere in the project:
using GlobalVariables;
int x = Globals.GlobalInt;
Globals.SetGlobalInt(888);
By "forcing" yourself, or another developer, to activate a distinct NameSpace, and specify the Class to access the global variable, and by limiting the setting of the global variable to a specific procedure invoked in the static class, I'd argue that you are creating code that is self-documenting, and code in which global variable use is rigorously controlled.
In the above example, in the VS Studio 2010 Pro IDE, in a project in which the GlobalVariables NameSpace has been activated by a 'using' statement: an attempt to directly set the global variable of the form:
Globals.GlobalInt = 122;
Is going to give you a 'red flag' the moment you type it, and a useful error when you try to build the project. imho that's valuable !