How does a “Variables introduce state”?

Question

I was reading the "C++ Coding Standards" and this line was there:

Variables introduce state, and you should have to deal with as little state as possible, with lifetimes as short as possible.

Doesn't anything that mutates eventually manipulate state? What does "you should have to deal with little state as possible" mean?

In an impure language such as C++, isn't state management really what you are doing? And what are other ways to "deal with as little state as possible" other than limiting variable lifetime?

Answer 1

Doesn't any mutable thing really manipulate state?

Yes.

And what does the "you should have to deal with little state" mean?

It means that less state is better than more state. More state tends to introduce more complexity.

In an impure language like C++, isn't state management really what you are doing?

Yes.

What are other ways to "deal with little state" other than limiting variable lifetime?

Minimize the number of variables. Isolate code that manipulates some state into a self-contained unit so that other code sections can ignore it.

Answer 2

Doesn't any mutable thing really manipulate state?

Yes. In C++, the only mutable things are (non-const) variables.

And what does the "you should have to deal with little state" mean?

The less state a program has, the easier it is to understand what it does. So you shouldn't introduce state that isn't needed, and you shouldn't keep it once you no longer need it.

In an impure language like C++, isn't state management really what you are doing?

In a multi-paradigm language like C++, there's often a choice between a "pure" functional or a state-driven approach, or some kind of hybrid. Historically, language support for functional programming has been fairly weak compared to some languages, but it's improving.

What are other ways to "deal with little state" other than limiting variable lifetime?

Restrict the scope as well as the lifetime, to reduce coupling between objects; favour local rather than global variables, and private rather than public object members.

Answer 3

state means that something is being stored somewhere so you can refer to it later.

Creating a variable, creates some space for you to store some data. This data is the state of your program.

You use it to do things with, alter it, compute with it, etc.

This is state, whereas the things you do aren't state.

In a functional language, you mostly deal only with functions and passing functions around like they were objects. Though these functions don't have state, and passing the function around, introduces no state (besides maybe inside the function itself).

In C++ you can create function objects, which are struct or class types which have operator()() overloaded. These function objects can have local state, though this is not necessarily shared among other code in your program. Functors (ie function objects) are very easy to pass around. This is about as close as you can imitate a functional paradigm in C++. (AFAIK)

Having little or no state means you can easily optimize your program for parallel execution, because there's nothing that can be shared among threads or CPU's, so nothing that contention can be created about, and nothing you have to protect against data races, etc.

Answer 4

State is simply stored data. Every variable is really some sort of state, but we usually use "state" to refer to data that is persistent between operations. As a simple, pointless example, you may have a class that internally stores an int and has increment() and decrement() member functions. Here, the internal value is state because it persists for the life of the instance of this class. In other words, the value is the state of the object.

Ideally, the state that a class defines should be as small as possible with minimal redundancy. This helps your class meet the single responsibility principle, improves encapsulation and reduces complexity. The state of an object should be entirely encapsulated by the interface to that object. This means that the result of any operation on that object will be predictable given the semantics of the object. You can further improve encapsulation by minimizing the number of functions that have access to the state.

This is one of the major reasons for avoiding global state. Global state may introduce a dependency for an object without the interface expressing it, making this state hidden away from the user of the object. Invoking an operation on an object with a global dependency may have varying and unpredictable results.

Answer 5

And what does the "you should have to deal with little state" mean?

This means that your classes should be as small as possible, optimally representing a single abstraction. If you put 10 variables in your class, most likely you are doing something wrong, and should see how to refactor your class.

Answer 6

To understand how a program works, you must understand its changes of state. The less state you have and the more local it is to the code that uses it, the easier this will be.

If you've ever worked with a program that had a large number of global variables you would understand implicitly.

Answer 7

Others have provided good answers to the first 3 questions.

And what are other ways to "deal with as little state as possible" other than limiting variable lifetime?

The key answer to question #1 is yes, anything that mutates eventually impacts state. The key then is to not mutate things. Immutable types, using a functional programming style where the result of one function is passed directly to the other and not stored, passing messages or events directly rather than storing state, calculating values rather than storing and updating them...

Otherwise you're left with limiting the impact of state; either via visibility or lifetime.