... subroutines ... extra returns ...

I don't understand these points.

Certainly using multiple returns and/or refactoring code into subroutines can, in general, be extremely useful for improving the readability/reliability/maintainability of code.

But the particular code example presented in Re: Number of times I've used goto in Perl has a rather unusual structure. There are two interleaved streams of function calls and instructions:

• optional functions that may be called only if no previous optional function failed;
• required function calls and instructions that must all be called in order even if any previous optional function call has failed.

Using multiple returns and/or refactoring into subroutines (or even (shudder) using nested if-elsif-else blocks or conditional goto statements), it would certainly be possible to replicate the control flow of the OPed code, but again, I can't see how it would be any improvement on anonymized user 468275's basic approach; indeed, it seems to me that it could only be much worse. Can you give an example of what you envision?

Yeah, I saw several things in that node. There was the topic of this thread (goto), the intro paragraph that said that this can conflict with 2 other things, and a prominent code comment suggesting that a label could be inserted if goto were used. And none of that seems to have anything to do (as far as I could figure out) with the alternating-&&= part of the code that you commented on. I agree that the &&= part of the code is interesting. I also fail to see where a goto would help any of the code shown.

So I was only addressing the topic that matched the thread, the opening paragraph, and the prominent comment in the code.

Perhaps it was actually desirable for the &&= short-circuiting to apply to all of the code so the better alternative was a lot of "goto failed if ! ...;" lines? That's my best guess, anyway.

For such a case, the better approach I would do would be to change:

sub do_lots_and_log {
    ...
    goto failed
        if  ! method1(...);
    ...

    log("yay!");
    return;

failed:
    log("boo!");
}
[download]

to:

sub do_lots_and_log {
    if( do_lots(...) ) {
        log("yay!");
    } else {
        log("boo!");
    }
}

sub do_lots {
    ...
    method1(...)
        or  return 0;
    ...
    return 1;
}
[download]

Sometimes "throw exception" is an even better solution than "early return", of course.

- tye