develooper Front page | perl.perl5.porters | Postings from June 2008

Re: [perl #56150] return return

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
June 23, 2008 02:33
Subject:
Re: [perl #56150] return return
Message ID:
20080623093328.GC32515@klangraum.plasmasturm.org
* Mark Mielke <mark@mark.mielke.cc> [2008-06-23 01:10]:
> If your suggestion is that "return" improves readability, I
> disagree that the addition of "return" will universally improve
> the ability for a person to read the code.

As long as you have the discipline to always, *always* write a
bare `return;` in functions that are meant not to return a value,
and the maintenance programmer who comes after knows of your
discipline in that matter, then using `return` when you do mean
to return a value is not necessary.

For everyone else, putting in an explicit `return` is a way to
state explicitly that “yes, I really did mean for this value to
be returned, I did not just forget to suppress it.”

> Perl programmers *must* be accustomed to code blocks returning
> the last value. This is how grep and map work. Any Perl
> programmer that cannot read this comfortably will have problems
> with these basic functions. If the programmer needs an explicit
> "return" to tell them what is happening, I would suggest it
> isn't about machine vs people but Perl vs C/Java.

It is never ever a concern of mine to make code readable to
people who are unfamiliar with the language. What concerns me is
how to communicate intent to subseqent readers of the code.

My point is about the situation in which a maintenance programmer
(or worse, an API client programmer working on a different
module) finds a 10-line function that contains no `return`,
especially if the return value is not used anywhere yet: now
s/he has to wonder whether that return value is part of its
public interface or not. If you put in an explicit `return`,
there is no doubt about what you meant.

As far as `map` and friends are concerned, if your blocks are
much longer than two simple statements, you should usually
reconsider readability. (Along the same line, I occasionally
write single-expression functions (that go on a single line and
don’t even unpack their @_), and sure, I omit the `return` in
those.)

As I said above, in theory it is enough to use an explicit
`return` to suppress leaking last value from the function in
cases where its public interface does not include any return
value. But that presumes that you and everyone else who works on
the codebase will have perfect discipline about this issue, *and*
that this is known among everyone who works on the codebase.

So putting in an explicit `return` should be your default, and
deviations from that rule should be individually considered.

Not because of what the machine will do, but because of what it
signifies to subsequent readers about what you meant to happen.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About