Static Member Variables in Classes

Once you start writing subroutines, a practical question comes up quickly: when code inside a subroutine works with a name, whose name is it, and who else is allowed to see it? Many beginners assume that every name inside a subroutine is connected to the rest of the program in the same way. That assumption leads to predictable surprises. This article sorts out which names a subroutine can reach, which of those names can influence the caller, and why the answer depends on where a name was originally declared.

A subroutine can work with three different kinds of variables. The first is a local variable, which the subroutine declares for its own use. The second is a formal parameter, which is the name in the subroutine's header that receives a value from whoever calls it. The third is a variable declared outside the subroutine, which the subroutine can still reach. These three categories differ in where their names come from and in how far their effects travel.

The diagram below shows the main sources of names a subroutine can use. Parameters and locals are both created for the subroutine, while the outer variables already existed before the subroutine ran. That single difference, whether a name belongs to the subroutine or to the wider program, explains most of the behavior discussed in the rest of this article.

A local variable is declared inside a subroutine and has no connection to the outside world. Its entire job is to support the internal workings of that subroutine. Because of this, a local variable never affects the rest of the program. The subroutine can create it, change it many times, and discard it, and nothing outside the subroutine notices.

This isolation is the main reason programmers prefer local variables for temporary calculations. The subroutine can use them freely without creating side effects that other code must keep track of. When a learner later asks when a local variable comes into existence and disappears during a call, the answer is tied to the subroutine's own execution: the local exists for the work of that subroutine and is not something the caller can rely on afterward.

A formal parameter is the mechanism for getting information into a subroutine. When the subroutine is called, the caller's values are dropped into the parameter names, and the subroutine works with those names from then on. Once execution of the subroutine begins, a parameter behaves much like a local variable. The parameter name is a fresh name inside the subroutine, even though it started with a value supplied by the caller.

The consequence for primitive types is direct. A change made to the parameter inside the subroutine has no effect on the rest of the program. The caller's variable keeps whatever value it had before the call. The diagram below compares the caller's variable and the parameter before and after the subroutine changes the parameter.

A variable defined outside a subroutine is treated differently from a parameter. It exists independently of the subroutine and is accessible to other parts of the program. Such a variable is called global to the subroutine, in contrast to the local variables defined inside it. A global variable can be used throughout the class in which it is defined and, if it is not declared private, in other classes as well.

Because the variable is shared, changes made to it inside a subroutine can have effects that extend beyond that subroutine. The diagram below follows one such change from the subroutine body to other parts of the program that read the same variable later.

Using a global variable inside a subroutine turns the variable into part of that subroutine's interface. The subroutine is communicating with the rest of the program through the shared variable, not only through its parameter list. The source describes this as a kind of sneaky, back-door communication. It is less visible than communication through parameters, and it risks breaking the principle that a black box should have an interface that is straightforward and easy to understand. A reader who sees only the subroutine header will not know that the shared variable is being read or changed.

The source is careful not to forbid the practice. Global variables are not always bad inside subroutines. If the global variable is treated as part of the subroutine's interface, the communication is acceptable. The source recommends asking, before you use a global variable in a subroutine, whether it is really necessary. A practical check is to ask whether the same data could be passed in as a parameter and, if so, whether passing it would make the subroutine's dependencies clearer.