got him

Since my previous example didn't really have return value, I am changing it slightly. So if I'm reading your suggestion of "rewriting that in 3 lines and a single nested scope followed by a single return", I think you mean it like this?

int retval = 0;

// precondition checks:
if (!p1) retval = -ERROR1;
if (p2) retval = -ERROR2;
if (!p3 && p4) retval = -ERROR3;

// business logic:
if (p1 && !p2 && (p3 || !p4))
{
    retval = 42;
}

// or perhaps would you prefer the business logic check be like this?
if (retval != -ERROR1 && retval != -ERROR2 && retval != -ERROR3)
{
    retval = 42;
}

// or perhaps you'd split the business logic predicate like this? (Assuming the predicates only have a value of 0 or 1)
int ok = p1;
ok &= !p2;
ok &= p3 || !p4;
if (ok)
{
    retval = 42;
}

return retval;

as opposed to this?

// precondition checks:
if(!p1) return -ERROR1;
if(p2) return -ERROR2;
if(!p3 && p4) return -ERROR3;

// business logic:
return 42;

Using a retval has the exact problem that you want to avoid: at the point where we do return retval, we have no idea how retval was manipulated, or if it was set multiple times by different branches. It's mutable state inside the function, so any line from when the variable is defined to when return retval is hit must now be examined to know why retval has the value that it has.

Not to mention that the business logic then needs to be guarded with some predicate, because we can't early return. And if you need to add another precondition check, you need to add another (but inverted) predicate to the business logic check.

You also mentioned resource leaks, and I find that a more compelling argument for having only a single return. Readability and understandability (both of which directly correlate to maintainability) are undeniably better with early returns. But if you hit an early return after you have allocated resources, you have a resource leak.

Still, there are better solutions to the resource leak problem than to clobber your functions into an unreadable mess. Here's a couple options I can think of.

1. Don't: allow early returns only before allocating resources via a code standard. Allows many of the benfits of early returns, but could be confusing due to using both early returns and a retval in the business logic
2. If your language supports it, use RAII
3. If your language supports it, use defer
4. You can always write a cleanup function

Example of option 1

// precondition checks
if(!p1) return -ERROR1;
if(p2) return -ERROR2;
if(!p3 && p4) return -ERROR3;

void* pResource = allocResource();
int retval = 0;

// ...
// some business logic, no return allowed
// ...

freeResource(pResource);
return retval; // no leaks

Example of option 2

// same precondition checks with early returns, won't repeat them for brevity

auto Resource = allocResource();

// ...
// some business logic, return allowed, the destructor of Resource will be called when it goes out of scope, freeing the resources. No leaks
// ...

return 42;

Example of option 3

// precondition checks

void* pResource = allocResource();
defer freeResource(pResource);

// ...
// some business logic, return allowed, deferred statements will be executed before return. No leaks
// ...

return 42;

Example of option 4

int freeAndReturn(void* pResource, const int retval)
{
    freeResource(pResource);
    return retval;
}

int doWork()
{
    // precondition checks

    void* pResource = allocResource();

    // ...
    // some business logic, return allowed only in the same form as the following line
    // ...

    return freeAndReturn(pResource, 42);
}

And I'm going to make you read those blocks because they are there for a damn reason. What are you even reading at this point if you're not reading the preconditions? That's how you end up dereferencing null pointers, when you have ten nested ifs you can barely see it on your screen

You said yourself they're equivalent. You either have to read the blocks in both cases or neither case.

You need to read the blocks to know what gets returned (either early or in a single return). You need to read the blocks to see what resources get created but not released. What are you hoping to achieve by only reading control flow?

At least with an early return you can stop reading.

You can say any execution flow controls are like gotos - continue, break, exceptions, switch, even ifs are not much more than special cases of gotos.

This is true regardless of the size of the function which shows that the size of the function isn’t the determinant

Logical clarity does tend to worsen as the function grows. In general, it is easier to make sense of a shorter function than a longer one. I don't know how you could even say otherwise.

Early returns are still great for argument validation. The alternative means letting the function execute to the end when it shouldn't, just guarded by if conditions - and these conditions any reader would have to keep in mind.

When a reader comes across an early return, that's a state they can free from their reader memory, as any code below that would be unreachable if that condition was met.