Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re^2: Stupid mistakes I repeatedly make

by dragonchild (Archbishop)
on Mar 28, 2005 at 13:47 UTC ( #442808=note: print w/replies, xml ) Need Help??

in reply to Re: Stupid mistakes I repeatedly make
in thread Stupid mistakes I repeatedly make

Works just as well . . .

But, it's not identical. The first consumes elements from @_ and the second doesn't. This means that functions which are iterating over @_ (for whatever reason) will not work with this refactoring.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

  • Comment on Re^2: Stupid mistakes I repeatedly make

Replies are listed 'Best First'.
Re^3: Stupid mistakes I repeatedly make
by Roy Johnson (Monsignor) on Mar 28, 2005 at 16:19 UTC
    There's always
    $_= shift for my ($i, $j, $k);
    which is pretty foolproof, though unconventional (read "ugly").

    Caution: Contents may have been coded under pressure.
Re^3: Stupid mistakes I repeatedly make
by DrWhy (Chaplain) on Mar 28, 2005 at 14:38 UTC
    I usually avoid shift unless I specifically need that array reduction behavior. In the context of parameter processing this is usually in OO-land when one method needs to call another with the same arguments it was given, e.g.

    sub method1 { my $self = shift; ... maybe do some stuff ... $self->method2(@_); ... maybe do some more stuff ... return $something; } # or even more simply sub method2 { shift->method3(@_) }

    Otherwise I always my($c,...) = @_;


    "If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

      I deliberately use shift now, more and more, for two reasons:
      • I have a personal coding convention that all methods should begin with "my $self = shift" (or "my $class = shift" for class methods).
      • It opens up a place for me to comment on the expected type:
        sub map_names { my $mapping = shift; # hashref of first-last names my $insensitive = shift; # boolean: should uppercase be the same? my @names = @_; # remaining parameters are names ... }
        With the "my ($x, $y, $z) = @_" style, I don't have a clean place for those comments, unless I want to break the list on the left across many lines (ick).

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

        With the "my ($x, $y, $z) = @_" style, I don't have a clean place for those comments, unless I want to break the list on the left across many lines (ick).

        Why not just put the type documentation into the embeded programmer documentation above your function? To call your function correctly, others need to know what they can and can't pass to it, and what will happen if they do. In other words, the type information is a valuable part of your function interface documentation.

        I embed the documentation for my function interfaces (as well as general 'programmer' documentation), within a special pod section, dedicated to the "programmerdocs" pod translator. When I need to extract the user documentation, the regular pod translator ignores the programmerdocs section. When I need to extract the programmer documentation, I have a twenty line perl script that extracts the 'programmmerdocs' section, and pipes the results of those sections to the standard pod translator.

        It's a bit of an abuse of the pod translator concept, but it works, and it keeps the two kinds of embeded documentation separatate, and easy to access. If anyone has a better method for keeping distict forms of documentation separate, I'm open to suggestions. So far, abusing pod has worked for me.

        I like extractable function documenation, because it allows a tester to write unit tests for all the functions without reading any of the implementation details. If the code doesn't match the documentation, the coder needs to fix one or both of his code or documentation.

        It also lets you do:
        sub foo { my $param = shift || croak 'Param must be supplied'; }

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (7)
As of 2021-04-20 07:17 GMT
Find Nodes?
    Voting Booth?

    No recent polls found