By ambiguous I mean someone can't tell what you intend to do just from looking at it; whether or not you intend to return something meaningful or if you're just falling off the end of the subroutine and don't care what it returns.
I understand what you mean by this, and I can even see why you think this is a good thing to do. It falls in the same category as people who have strict rules when to use single quotes, and when to use double quotes (I intend to do interpolation when I use double quotes), and who never use a map block if they don't intend side-effects.I also think this is a very bad idea (TM). You (and others, see examples in previous paragraph) assign (meta-)meaning to statements that isn't there. Now, I agree that it's good to have coding standards, and to be rigorous and consistent about them. But you shouldn't derive meaning from them. Because one day, when you least expect it, it'll bite you. One day, you'll look at a subroutine whose last expression isn't preceeded by a return, and based on that, you decide to ignore the return value. But it was important, and you shouldn't have. Perhaps when originally coding your subroutine, you made a mistake, and forgot the return (it's not something you can really test for - except perhaps by putting a comment next to it, and parsing the source code from your test suite; but if you have the comment there anyway, no need for the convention). Or the code was modified, or written, by someone else, and you didn't realize it.
IMO, if two piece of code do the same thing, they should mean the same thing. It gives you less surprises.
In reply to Re^14: "advanced" Perl functions and maintainability
by Anonymous Monk
in thread "advanced" Perl functions and maintainability
by geektron
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |