最近，我决定在我的代码上更频繁地使用
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上所讨论的一样，它也是not necessarily evil。
将上面的代码段更改为…
sub perl_critics_way_to_unpack {
my ($variable1,$variable2) = @_;
my $result = $variable1 + $variable2;
return $result;
}
…工作也很好，但我觉得很难阅读。我也读过Damian Conway的书Perl Best Practices，而且我不太明白我最喜欢的打包方式是否符合他的建议，以避免直接使用@_，就像Perl::Critic所暗示的那样。我一直觉得康威正在谈论的这个难题，就像：
sub not_unpacking {
my $result = $_[0] + $_[1];
return $result;
}
上面的例子是坏的，很难阅读，我永远不会考虑写一个生产代码。
那么简而言之，为什么Perl::Critic认为我喜欢的方式不好？我是否真的通过使用转移来发起一场恶毒的罪行？
这是否与我自己以外的人认为应该与Perl::Critic维护者一起成长？
解决方法
简单的答案是Perl :: Critic在这里没有遵循PBP。该 明确地指出，转换成语不仅可以接受，而且 在某些情况下实际上是偏好的。