in reply to Re^2: Practical example of "Is Perl code maintainable"
in thread Practical example of "Is Perl code maintainable"

In sum: "If we extend this practice to ridiculous extremes, then we end up doing ridiculous things. Therefore, the practice as proposed is certainly ridiculous."

Although already having acquired a preference for avoiding using shift in particular without arguments (having actually run into code that got moved into a subroutine and thus broken, having seen uglier work-arounds for things like $hash{shift}, and just coming to the conclusion that saving three keystrokes doesn't balance the even minor loss of clarity), I finally fully adopted a "best practice" after a frustrating bought with Test.

I was trying to fill in some details that were not clearly explained by the documentation as to how the arguments to ok() are used. Looking at the source (search for "sub ok") we find a fairly short routine so it should be no problem to figure out how the arguments are used. Searching for @_ or $_[ finds no real uses of arguments (only checks as to whether @_ is empty). So next I had to search for all of the different ways that @_ might be used implicitly. Do you know them all off the top of your head? Are you sure? Personally, I didn't want to perform that mental exercise at that point. Turning up a few "hidden" uses of @_ still left me wondering if I'd found them all.

So I endeavor to no longer leave such mental land-mines for others (nor for my future self). No, I was not a Perl newbie at the time ( didn't exist when I was a Perl newbie).

Now, although I find the small improvement offered by replacing "shift" with "shift @_" to be wholely worthwhile in that particular case, I think the clarity of that subroutine would have been even more helped had shift not been used at all and, even more so, if the argument processing had not been spread over nearly the entire 60 lines of the subroutine. But those are more complex style points that I'm not convinced aren't worth "violating" in some situations so I keep them around as style guidelines to be weighed.

But I see no even moderate down-side to being explicit with @_, so being explicit with @_ is something that I just always try to do, saving myself from spending any time wondering whether I should leave it off or not. It also saves me from having to worry about using shift by itself in a bareword context and wondering whether @ARGV was really intended. I also enjoy the presense of @ making it that much faster to parse the code.

You can certainly assume that someone's reasons for having a policy are likely "cargo cult" in the face of no evidence either way. Making a choice to prefer to see other people in such a light is a personal matter. I note that you gave not a single benefit to leaving out @_, so I'll just presume that this is due to a personality flaw on your part, since my experience is that you wouldn't leave out such arguments if you had any. ;)

- tye        

Replies are listed 'Best First'.
Re^4: Practical example of "Is Perl code maintainable" (reason)
by BrowserUk (Pope) on Aug 13, 2007 at 23:16 UTC
    ... so I'll just presume that this is due to a personality flaw on your part ...

    Which is exactly why I chose to explore my thoughts and reasoning on the subject with Limbic~Region where I knew I would get a polite, respectful response even if he didn't agree with me.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.