为什么 Perl::Critic 不喜欢使用 shift 来填充子例程变量？

Question

最近，我决定开始在我的网站上更频繁地使用 Perl::Critic代码。在使用 Perl 编程近 7 年之后，我已经习惯了大多数 Perl 最佳实践很长一段时间，但我知道总有改进的空间。但一直困扰我的一件事是 Perl::Critic 不不喜欢我为子例程解压 @_ 的方式。举个例子：

sub my_way_to_unpack {
    my $variable1 = shift @_;
    my $variable2 = shift @_;

    my $result = $variable1 + $variable2;
    return $result;
}

这就是我一直这样做的方式，并且正如 PerlMonks 和 Stack Overflow 上讨论的那样，它的 也不一定是邪恶的。

将上面的代码片段更改为...

sub perl_critics_way_to_unpack {
    my ($variable1, $variable2) = @_;

    my $result = $variable1 + $variable2;
    return $result;
}

...也有效，但我发现它更难阅读。我还读过 Damian Conway 的书 Perl 最佳实践，但我不太明白我的首选方法解包属于他的建议，避免直接使用 @_ ，如 Perl::Critic 暗示着。我一直觉得康威在谈论肮脏的东西，例如：

sub not_unpacking {
    my $result = $_[0] + $_[1];
    return $result;
}

上面的例子很糟糕并且难以阅读，我永远不会考虑在一段生产代码中编写它。

简而言之，为什么 Perl::Critic 认为我的首选方式不好？难道我真的犯下了利用shift拆包的滔天大罪吗？

除了我之外，其他人是否认为应该通过 Perl::Critic< /a> 维护者？

Answer 1

简单的答案是 Perl::Critic 在这里没有遵循 PBP。这
书中明确指出，转变习惯用法不仅可以接受，而且
在某些情况下实际上是首选。

Answer 2

使用 --verbose 11 运行 perlcritic 解释了这些策略。不过，这两种解释似乎都不适用于您。

Always unpack @_ first at line 1, near 
'sub xxx{ my $aaa= shift; my ($bbb,$ccc) = @_;}'.
  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 3

重要的是要记住，Perl 最佳实践中的很多内容只是一个人对外观的看法最好的或最容易使用的，如果你用其他方式来做也没关系。达米安在本书的介绍性文字中也说了同样的话。这并不是说全部都是这样——其中有很多东西是绝对必要的：例如，使用strict。

因此，当您编写代码时，您需要自己决定自己的最佳实践是什么，而使用 PBP 是一个很好的起点。然后与你自己的标准保持一致。

我尝试遵循 PBP 中的大部分内容，但 Damian 可以拥有我的子例程参数 shift 和我的 es，除非他从我冰冷、死气沉沉的指尖撬开它们。

对于 Critic，您可以选择要执行的策略，甚至可以创建自己的策略（如果尚不存在）。

Answer 4

在某些情况下，Perl::Critic 无法精确地执行 PBP 指南，因此它可能会执行尝试符合 Conway 指南精神的近似值。我们完全有可能误解或误用了 PBP。如果您发现某些内容有问题，请将错误报告邮寄至 [email protected ] 我们会立即调查。

谢谢，

-杰夫

Answer 5

我认为如果不是真的有必要，你通常应该避免轮班！

刚刚遇到这样的代码：

sub way {
  my $file = shift;
  if (!$file) {
    $file = 'newfile';
  }
  my $target = shift;
  my $options = shift;
}

如果您开始更改此代码中的某些内容，那么您很可能会意外更改轮班顺序，或者可能跳过一个轮班，然后一切都会向南发展。此外，它很难阅读 - 因为你不能确定你真的看到了子程序的所有参数，因为下面的某些行可能是某个地方的另一个转变......如果你在中间使用一些正则表达式，它们可能会替换 $_ 和奇怪的事情开始发生...

使用解包 my (...) = @_ 的直接好处是您可以复制 (...) 部分并将其粘贴到调用方法的位置并有一个漂亮的签名： ）您甚至可以事先使用相同的变量名称，而不必更改任何内容！

我认为移位意味着列表操作，其中列表的长度是动态的，并且您希望一次处理一个元素，或者您明确需要一个没有第一个元素的列表。但如果您只想将整个列表分配给 x 参数，您的代码应该使用 my (...) = @_; 来表示。没有人会感到奇怪。