是“移位”吗？处理 Perl 子程序参数的邪恶？

Question

我经常使用 shift 来解压函数参数：

sub my_sub {
    my $self = shift;
    my $params = shift;
    ....
}

然而，我的许多同事都在宣扬 shift 实际上是邪恶的。您能解释一下为什么我应该选择

sub my_sub {
    my ($self, $params) = @_;
    ....
}

shift吗？

Answer 1

使用 shift 来解压参数并不是邪恶的。这是一种常见的约定，并且可能是处理参数的最快方法（取决于参数的数量以及它们的传递方式）。下面是一种常见场景的一个示例：一个简单的访问器。

use Benchmark qw(cmpthese);

sub Foo::x_shift { shift->{'a'} }
sub Foo::x_ref   { $_[0]->{'a'} }
sub Foo::x_copy  { my $s = $_[0]; $s->{'a'} }

our $o = bless {a => 123}, 'Foo';

cmpthese(-2, { x_shift => sub { $o->x_shift },
               x_ref   => sub { $o->x_ref   },
               x_copy  => sub { $o->x_copy  }, });

我的机器上 perl 5.8.8 的结果：

            Rate  x_copy   x_ref x_shift
x_copy  772761/s      --    -12%    -19%
x_ref   877709/s     14%      --     -8%
x_shift 949792/s     23%      8%      --

并不引人注目，但确实如此。始终在目标硬件上的 Perl 版本上测试您的场景，以确保找到答案。

如果您想要移走调用者，然后调用 SUPER:: 方法，将剩余的 @_ 传递为-是。

sub my_method
{
  my $self = shift;
  ...
  return $self->SUPER::my_method(@_);
}

但是，如果我在函数顶部有一系列很长的 my $foo = shift; 操作，我可能会考虑使用来自 @_ 的大量副本。但一般来说，如果您有一个函数或方法需要多个参数，请使用命名参数（即捕获 %args 哈希中的所有 @_或者期望单个散列引用参数）是更好的方法。

Answer 2

这不是邪恶的，而是一种品味。您经常会看到一起使用的样式：

sub new {
    my $class = shift;
    my %self = @_;
    return bless \%self, $class;
}

当有一个参数或当我想以不同于其他参数的方式对待前几个参数时，我倾向于使用 shift。

Answer 3

正如其他人所说，这是一个品味问题。

我通常更喜欢将参数转换为词法，因为它为我提供了一个标准位置来声明一组将在子例程中使用的变量。额外的冗长给了我一个放置评论的好地方。它还可以轻松地以简洁的方式提供默认值。

sub foo {
    my $foo = shift;       # a thing of some sort.
    my $bar = shift;       # a horse of a different color.
    my $baz = shift || 23; # a pale horse.

    # blah
}

如果您确实关心调用例程的速度，则根本不要解压您的参数 - 使用 @_ 直接访问它们。请小心，这些是对您正在使用的调用者数据的引用。这是 POE 中的常见习语。 POE 提供了一堆常量，您可以使用这些常量按名称获取位置参数：

sub some_poe_state_handler {
    $_[HEAP]{some_data} = 'chicken';
    $_[KERNEL]->yield('next_state');
}

现在，如果您习惯性地使用 shift 解压参数，则可能会遇到一个愚蠢的大错误：

sub foo {
    my $foo = shift;
    my $bar = shift;
    my @baz = shift;

    # I should really stop coding and go to bed.  I am making dumb errors.

}

我认为一致的代码风格比任何特定风格更重要。如果我所有的同事都使用列表分配风格，我也会使用它。

如果我的同事说使用 Shift 来解包有一个大问题，我会要求演示为什么它不好。如果案件属实，那么我会学到一些东西。如果案件是假的，我可以反驳它并帮助阻止反知识的传播。然后我建议我们确定一个标准方法并在未来的代码中遵循它。我什至可能尝试设置 Perl::Critic 策略来检查已决定的标准。

Answer 4

将 @_ 分配给列表可以带来一些有用的附加功能。

它使得稍后在修改代码时添加其他命名参数变得稍微容易一些。有些人认为这是一个功能，类似于用尾随“，”完成列表或散列使得在中追加成员稍微容易一些未来。

如果您习惯使用这个习惯用法，那么移动参数可能看起来有害，因为如果您编辑代码以添加额外的参数，如果您不注意的话，最终可能会出现一个微妙的错误。

例如，

sub do_something {
 my ($foo) = @_;
}

稍后编辑为

sub do_something {
  my ($foo,$bar) = @_; # still works
}

但是

sub do_another_thing {
  my $foo = shift;
}

如果另一位教条地使用第一种形式的同事（也许他们认为转变是邪恶的）编辑您的文件并心不在焉地更新此文件以供阅读

sub do_another_thing {
  my ($foo, $bar)  = shift; # still 'works', but $bar not defined
}

，他们可能会引入一个微妙的错误。

当要一次分配的参数数量较少时，在垂直空间中分配给 @_ 可以更加紧凑和高效。如果您使用命名函数参数的哈希样式，它还允许您提供默认参数，

例如

 my (%arguments) = (user=>'defaultuser',password=>'password',@_);

我仍然认为这是风格/品味的问题。我认为最重要的是一致地应用一种风格或另一种风格，遵循最少惊喜的原则。

Answer 5

我不认为 shift 是邪恶的。使用 shift 表明您愿意实际命名变量 - 而不是使用 $_[0]。

就我个人而言，当函数只有一个参数时，我会使用 shift。如果我有多个参数，我将使用列表上下文。

 my $result = decode($theString);

 sub decode {
   my $string = shift;

   ...
 }

 my $otherResult = encode($otherString, $format);

 sub encode {
   my ($string,$format) = @_;
   ...
 }

Answer 6

对列表分配进行了优化。

我能找到的唯一参考是这个。

5.10.0 无意中禁用了优化，从而导致
列表中可测量的性能下降
赋值，例如经常用于
从 @_ 分配函数参数。
优化已恢复，
并修复了性能回归问题。

这是受影响的性能回归的示例。

sub example{
  my($arg1,$arg2,$arg3) = @_;
}

Answer 7

Perl::Critic 是你的朋友。它遵循 Damian Conway 的《Perl 最佳实践》一书中制定的“标准”。使用 --verbose 11 运行它可以给你解释为什么事情不好。不首先在您的潜艇中解开@_ 的严重性为 4 级（满分 5 级）。例如：

echo 'package foo; use warnings; use strict; sub quux { my foo= shift; my (bar,baz) = @_;};1;' | perlcritic -4 --verbose 11

Always unpack @_ first at line 1, near 'sub quux { my foo= shift; my (bar,baz) = @_;}'.
  Subroutines::RequireArgUnpacking (Severity: 4)
    Subroutines that use `@_' directly instead of unpacking the arguments to
    local variables first have two major problems. First, they are very hard
    to read. If you're going to refer to your variables by number instead of
    by name, you may as well be writing assembler code! Second, `@_'
    contains aliases to the original variables! If you modify the contents
    of a `@_' entry, then you are modifying the variable outside of your
    subroutine. For example:

       sub print_local_var_plus_one {
           my ($var) = @_;
           print ++$var;
       }
       sub print_var_plus_one {
           print ++$_[0];
       }

       my $x = 2;
       print_local_var_plus_one($x); # prints "3", $x is still 2
       print_var_plus_one($x);       # prints "3", $x is now 3 !
       print $x;                     # prints "3"

    This is spooky action-at-a-distance and is very hard to debug if it's
    not intentional and well-documented (like `chop' or `chomp').

    An exception is made for the usual delegation idiom
    `$object->SUPER::something( @_ )'. Only `SUPER::' and `NEXT::' are
    recognized (though this is configurable) and the argument list for the
    delegate must consist only of `( @_ )'.

Answer 8

它本质上并不是邪恶的，但使用它来逐一完成子例程的参数相对较慢，并且需要更多的代码行。