"return" in def

[Aaron Brady]

On Dec 29, 7:00 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Mon, 29 Dec 2008 05:31:17 -0800, Aaron Brady wrote:
> > One style of coding I heard about once only permits returns at the end
> > of a function.  It claims it makes it easier to see the function as a
> > mathematical object.
>
> That's silly. You treat the function as a black box: input comes in, and
> output comes out. You have no idea of what happens inside the black box:
> it could loop a thousand times, take 150 different branches, or take one
> of 37 different exit points. From the outside, it's still exactly like a
> mathematical object. Internal complexity is irrelevant. This is why
> mathematicians can perform algebra on complicated functions like Bessel's
> function (of the first or second kind), without needing to care that
> actually calculating Bessel's function is quite tricky.
>
> What I think the one-return-per-function style is aiming at is that it is
> (sometimes) easier to analyse the internals of the function if there are
> few branches. The more complicated branches you have, the harder it is to
> analyse the function. Early exits on their own are not the cause of the
> complexity: it's the number of branches leading to the early exit that
> causes the problem.

You'd think they would have noticed that.  Eliminating early exits
doesn't change the number of branches!

> Avoiding early exits is an over-reaction to the Bad Old Days of spaghetti
> code. But used wisely, early exists can simplify, not complicate, code.

To make your case, you don't even need to prove that a wise early exit
can simplify.  You just need that an early exit can simplify.  (The
conclusive case is the early exit is better.  For that, it's
sufficient but not necessary to show that simplicity is your reader's
highest priority.  What's instructive about that is the
counterexample: when is simpler not better?  (Not rhetorical.  Or, if
never, then it's the top priority and consistent with every top
priority, if my calculations are correct; but it remains to show that
early exits can simplify.)

snip better simpler

> The second version has double the number of lines of code of the first.
> It introduces an extra variable "found_item" and two extra if blocks. I
> don't think the claim that the version with an early exit is more
> complicated than the version without can justified.

In a lab report, this is the part where the author would be arguing,
"And the object accelerated at 9.8 m/s^2, which proves our
hypothesis."  I think you're showing that early exits can simplify,
but you're bringing in more factors.  I think you're trying to say
that less lines of code is simpler, and less variables is simpler.
Those lack proofs.

You need:
M: Less lines of code is simpler.
m: Simpler is always better.
C: Less lines of code is better.

Or something.  But no amount of thrashing, bludgeoning, wibbling,
whimpering, or beating children with blunt objects, is going to change
your reader's knowledge of good.  Only experience is.  Fine fine, so
leather belts are bad.  That doesn't make fewer lines of code good.

However, the burden of proof is (definitely IMO) on the people that
are unilaterally opposed to early returns.  They need:
M: Early exits are never simpler.
m: Simpler is always better.
C: Early exits are never better.

Oddly enough, you share a minor premise.