Origin of "a method should return a value or have side-effects, but not both"

Question

I read once that a method should either have a return value (and be referentially transparent), or have side-effect(s), but not both. I cannot find any references to this rule, but want to learn more about it.

What is the origin of this advice? Out of what person or community did it arise?

Extra credit: What is the claimed benefit of following this advice?

Answer 1

According to Greg Young, this idea originated from Bertrand Meyer: Command-Query separation.

It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, Asking a question should not change the answer.¹ More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.

1: Eiffel: a language for software engineering slide 43-48

In Domain Driven Design, this is similar to Command-Query-Read Separation/Segregation (CQRS), as named by Greg Young.

Greg Young took the idea of CQS from Bertrand to name CQRS as mentioned by Martin Fowler in this CQRS article

Benefits

• The Read (Query) part can be scaled/tweaked differently from the Write (command) part. Separating the two would prevent either from getting in the way of each other when optimization/performance is key.

Read the article in the Martin Fowler link for more.

Answer 2

I don't know where it comes from, but it is good advice and fairly straight-forward to understand.

Any sanely designed program will be broken up into various parts, combined and composed in various ways. The harder it is to reason about what any particular part does, the harder it will be to make sure that your program will react in a predictable manner.

Isolating the parts that produce side-effects makes the rest easier to reason about, test, and debug. Reducing the number of side-effects in each part that does generate a side-effect will make that part easier to work with in the same manner.

If you decompose it even further, a return value is an effect. Side-effects are an effect. A function should only produce 1 effect (if possible) because the greater number of inputs and effects a function has, the greater the difficulty in reasoning about what it actually does.

Answer 3

Extra credit: What is the originally claimed benefit of following this advice?

One of the benefits of separating return value from side effects is that it removes a potential problem which may be caused by short-circuit evaluation.

bool FooWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

bool BarWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

void BadShortCircuitEvaluation()
{
    // the programmer's intent is to have side effects of both functions
    if (FooWithSideEffect() && BarWithSideEffect() ) {
        // do something
    }

    // in case FooWithSideEffect() returns true, 
    // then BarWithSideEffect() is not called at all
    // because of short-circuit evaluation
}