Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Returning undef: The point I would like Damian to reconsider

by shmem (Chancellor)
on Jun 22, 2007 at 12:43 UTC ( #622780=note: print w/replies, xml ) Need Help??


in reply to Returning undef: The point I would like Damian to reconsider

Don't change subroutine results based on list or scalar context.

Why? I have useful subroutines that produce data and behave different in void, scalar and list context:

$thingy -> foo (1,2); # results printed to current filehandl +e $string = $thingy -> foo (1,2); # results returned as a single string @lines = $thingy -> foo (1,2); # results returned as a bunch of lines

and I don't see that as a bad practice. Works like expected and is documented. The alternative would be to shove the result explicitly through three other subs:

$thingy -> foo (1,2) -> to_output_channel; $string = $thingy -> foo (1,2) -> as_string; @lines = $thingy -> foo (1,2) -> as_list;

which gains me what exactly? Perl is context aware, even builtins do change their result depending on context, eg localtime. Why should I avoid perl's dwimmery? Should I avoid localtime and roll my own?

update: I have PBP on my shelf as well, and my biggest critic to it is about its title. It should have been named "Damian Conway's Coding Style", or "Perl Pitfalls" subtitle "and how to avoid them", or even "Code Perl Robustly" subtitle "without knowing all of perl".

My biggest critic upon Perl::Critic is that it enforces PBP's bad title as a standard, and where it could help you it doesn't, and will never: it can't tell whether you know what you are doing or have fallen into a trap, since it can't read your mind.

update 2: Personally I think that the rule "Use a bare return to return failure" cannot be a rule, since its text omits context. It's just bad worded and should be:

To return failure, use a bare return in list context, undef in scalar or void context. Set $@ to something meaningful.
Perl::Critic should handle the rule that way.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Replies are listed 'Best First'.
(OT) Re^2: Returning undef: The point I would like Damian to reconsider
by Argel (Prior) on Jun 22, 2007 at 19:40 UTC
    I ++'d your post but I disagree about your comments on the title of PBP. The book is full of well thought out recommendations that have been vetted by several members of the Perl community so I really do not see a problem with the name. Yes there will be some cargo cult type followers and yes, incompetent management will want to use it as a style guide. But really, given the choice between PBP and an in-house standard cobbled together by said incompetent management which would you prefer!? Overall I think the Perl community has needed something like PBP for a long time and the benefits of its existence far outweigh the negatives (including the name).
      I disagree about your comments on the title of PBP.
      ...
      the benefits of its existence far outweigh the negatives (including the name).

      Don't you see a contradiction here? So far you have defended the book, and I agree. You did not, though, explain why you disagree with me saying the title is bad - you just say it doesn't matter.

      Well, for me, it matters.

      But really, given the choice between PBP and an in-house standard cobbled together by said incompetent management which would you prefer!?
      What choice is that? Given the choice between a burger from <insert-junk-food-company-here> and your own fried shoe soles without salad and no onion, what would you prefer?

      I would see this most excellent book from Damian Comway as a style guide or vade mecum to gain perl insight and develop a good inhouse coding standard, rather than having the book as a whole imposed as such, without reading it, and merely because of its title.

      Which means: if anybody, including the PHB, after reading it gets enlightened and shouts "hey, these are really jolly well best perl practices!" and goes to introduce a subset or all as standard, that's perfectly fine.
      It is not ok if someone comes and says "here, have Perl Best Practices. It's standard now." - "Why?" - "Because they are. Can't read the title?"

      --shmem

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                    /\_¯/(q    /
      ----------------------------  \__(m.====·.(_("always off the crowd"))."·
      ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
        Does the title matter? I think given any good to great choice that it doesn't (while I'm here I'll throw out "Writing Perl with Style"). Why? Because the people that blindly follow it and the people that force it on others without due consideration would do so anyway!

        Okay, so maybe the title does matter a little bit. You are concerned about management using the title to justify using it as a coding standard. But what about the reverse? Developers could just as easily use the title to help finally get a coding standard in place.

        As for choice, I think the better analogy is a gourmet hamburger from say Blueberry Hill here in St. Louis vs. one from a fast food chain, but that's dependant on one's opinion of the book.

        Lets face it, a book like PBP has been long overdue. That coupled with the high quality of it leads me to believe we will not see something similar to it for some time. Throw in the input from several members of the Perl community and, well, quite frankly, I think the title fits.

Re^2: Returning undef: The point I would like Damian to reconsider
by princepawn (Parson) on Jun 22, 2007 at 20:30 UTC
    and I don't see that as a bad practice. Works like expected and is documented. The alternative would be to shove the result explicitly through three other subs:
    $thingy -> foo (1,2) -> to_output_channel; $string = $thingy -> foo (1,2) -> as_string; @lines = $thingy -> foo (1,2) -> as_list;
    which gains me what exactly?
    It gains you
    1. explicit clarity of intent
    2. 3 parameterizable output methods
    3. 3 methods which can be re-used or overloaded as needed
    4. The ability to call all 3 output methods, none or any combination simply by mixing/matching method calls.
    Should I avoid localtime and roll my own?
    Well, no. Try Date::localtime or Time::Local or anything in the DateTime hierarchy.


    Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality
      1. explicit clarity of intent

      I have that on the LHS.

      2. 3 parameterizable output methods
      3. 3 methods which can be re-used or overloaded as needed
      4. The ability to call all 3 output methods, none or any combination simply by mixing/matching method calls.

      No call for those, since that doesn't gain me anything.

      You missed my point. Context awareness is a key concept of Perl. Deprecating context awareness with regard to subroutine return is tantamount to crippling the language.

      Try Date::localtime

      No such module... ;-)

      --shmem

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                    /\_¯/(q    /
      ----------------------------  \__(m.====·.(_("always off the crowd"))."·
      ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://622780]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (9)
As of 2020-07-03 14:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?