Front page | perl.perl5.porters |
Postings from June 2008
* 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