R. Joseph Newton wrote:
> Paul Johnson wrote:
> > To my mind,
> > return if $target eq "MAIN";
> > at the top of a sub is a lot more helpful than making me search all the
> > way down to the botttom to see if there is anything after the conditional.
> >
> > And it's probably a lot less likely that the next person to edit that sub
> > will goof up by adding something where it shouldn't be.
> >
> > Slavish devotion to the single exit point paradigm can produce some
> > wonderfully messy code, all scrunched up at the right of the screen.
> >
> > Then again, I probably wouldn't merge those two original lines either.
> >
> > --
> > Paul Johnson - [EMAIL PROTECTED]
> > http://www.pjcj.net
>
> Ditto--on both points. The original formulation was just fine.
Brian Ling wrote:
>
> my $target = getTarget();
> If ( $target eq "MAIN" ) { return }
> #do lots of other stuff with value of target
I wouldn't disagree, except that it's the perfect place to use
return If $target eq "MAIN"
or
$target eq "MAIN" and return
to cut down on the furniture.
> Unless the $target variable was meant simply to decide on a return, it makes more
> sense to assign its value--one task, one line, and check it for validity--another
> task
> entirely, on a line of its own.
So presumably you're against
while ( my $line = <FH> ) {
:
}
on the same grounds? :)
> The only thing it lacked was a meaningful return value. Since the getTarget function
> provided enough information to decide in favor of an early exit, this information
> should probably be passed on more explicitly, perhaps just by returning 0 rather
> than undef.
I might buy
... this information could /possibly/ be passed on ...
A simple
return;
is /explicitly/ not returning a value, which is fine. The fact that you get 'undef' if
you
use the subroutine call as a value is irrelevant.
I don't believe a subroutine should always return a value just because it /can/. That
value is only useful if the calling code needs to behave differently depending on
the action of the subroutine. More often than not there's simply no point in passing
any value back to the calling code at all. Coding a return value that isn't used just
makes you look for subtleties that aren't there, and can lead (with the 'single exit
point' strategy) to the nightmare of dozens of subroutines which uselessly have a
'return 1' as their final statement. I do wish though that there was a better
distinction
between returning control and returning a value. In Perl it's made slightly worse
because
you can have both a 'return' without a value and a value without a 'return' (on the
last
line of the subroutine).
Cheers,
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
