http://qs321.pair.com?node_id=442665


in reply to Stupid mistakes I repeatedly make

my( $n, $m, $o ) = shift;

[download]

I used to do this one all the time also. I just got in the habit of not using shift. Instead I'd do: 

my ( $n ) = @_;

[download]

Works just as well and is nearly impossible to screw up if you need more variables.

Replies are listed 'Best First'.
Re^2: Stupid mistakes I repeatedly make
by dragonchild (Archbishop) on Mar 28, 2005 at 13:47 UTC
    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.

[reply]
      There's always 
      $_= shift for my ($i, $j, $k);

      [download]
      which is pretty foolproof, though unconventional (read "ugly").
      Caution: Contents may have been coded under pressure.
[reply]
[d/l]
      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(@_) }

      [download]

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

      --DrWhy

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

[reply]
[d/l]
[select]
        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
  ...
}

          [download]
          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.

[reply]
[d/l]
Re^2: Stupid mistakes I repeatedly make
by Anonymous Monk on Mar 28, 2005 at 20:51 UTC
    I'm the other way. I don't like things being in @_ unless they need to be passed down. In addition, in terms of english, I prefer the paralel structure of using shift multiple times. You'll often see me write: 
    my($n,$m,$o) = (shift,shift,shift);

    [download]
    which I think is rather elegant... in addition, having to add another shift when I add another variable of input (if I do) generally makes me think over the results and implementation of adding one, which is good :)
[reply]
[d/l]
[select]

In Section Meditations