The open closed principle of Object Oriented Programming [pdf]. The two attributes of this principle are "open for extension" and "closed for modification". This is the same as encapsulation where data is maintained privately and a public interface to access that data is strongly defined. Both of these are to protect the integrity of the component and not allow it to be modified willy nilly from external objects. The end result of this is that all member variables should be private.

This can be a major pain, for instance writing out Java Beans and their getter and setters can be painful. Worse, engineers discovering that typing it all out was a productivity drain instead decided we should type them out in XML first and then have them mapped to Java Beans. Such is the warped and narcissistic mind of the software engineer. The counter argument is that most getter and setters are just that, they don't place any restrictions on the argument of the setter such as validation, especially in strongly typed languages, so they end up looking like code litter.

A follow on consequence of all member variables should be private is that there should be no global variables as it can never be closed;

No module that depends upon a global variable can be closed against any other module that might write to that variable. Any module that uses the variable in a way that the other modules don't expect, will break those other modules. It is too risky to have many modules be subject to the whim of one badly behaved one.

There is always a temptation in complex systems such as javacript ones to have global variables. Occasionally they can pop out through bad scoping - such as leaving off a var when it is initialized in a method - and escape the intended block scoping.