in reply to Re: What does this mean
in thread Code explanation needed (was: What does this mean)

"I love the smell of sarcasm in the morning. Smells like..." No wait, wrong Apocalypse.

You can't optimize away function calls, since they're referenced, and so, clearly are present in some other place. That would be silly, but then, I'm sure that was the point.

Remember that the condition was that duped_ids would be called on those lines that had > 1 number of entries, and it would appear that you are calling it here on the first.

Also, call me crazy, but I despise labels. They're just not right. Maybe if you're programming in assembler, sure, you need labels, but in Perl? You can almost always avoid using them.
my $found; foreach (@file) { if (/^\Q$storeline|\E/ && $found++) # First hit skipped { duped_ids($storeline); return; } } unless ($found) { no_match($storeline); return; }
As they say in English: "Voila!"

Now I'll admit I have a sneaking suspicion that somewhere else in the code there is some nonsense like foreach (@codes) { foo($_) } but I can't say for sure.

Replies are listed 'Best First'.
Re: What does this mean
by Abigail-II (Bishop) on Jun 10, 2002 at 14:49 UTC
    Funny thing is, Larry added labels and the {last|next|redo} LABEL syntax to avoid having code with temporary variables like yours.... Do a man perlsyn and skip to "Here's how a C programmer might code".

    Abigail

      To address that specific example, if you re-wrote it as a subroutine, you could just return and be done with it. There is no need for a last LABEL when you do something like that.
      sub foo { my ($ary1, $ary2) = @_; foreach my $wid (@$ary1) { foreach my $jet (@$ary2) { last if ($wid > $jet); $wid += $jet; } } return; } foo(\@ary1, \@ary2);
      Sure, you can use LABELs to reduce what I might term "flag variables", or variables that merely represent a condition, but with a little re-engineering, you can usually eliminate those and still not use LABELs.

      Update:
      I had put a return if ($wid > $jet); but this was incorrect, and this would explain why my remarks seem kind of incoherent.
        I guess you missed the It's safer because if code gets added between the inner and outer loops later on, the new code won't be accidentally executed in the documentation.

        Your "put it in a sub" is a red herring. It doesn't add anything (after all, your return is outside the outer loop anyway.

        Abigail