问题标签 [perl-critic]

为什么opendir没有与 Perl Best Practices 中相同open的策略？

我正在考虑至少这两项政策：

• Perl::Critic::Policy::InputOutput::ProhibitBarewordFileHandles
• Perl::Critic::Policy::InputOutput::RequireBriefOpen

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

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

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

...也可以，但我发现它更难阅读。我还阅读了 Damian Conway 的《Perl Best Practices 》一书，但我并不真正理解我喜欢的解包方法如何符合他的建议，即避免@_直接使用，正如Perl::Critic所暗示的那样。我一直认为康威在谈论肮脏，例如：

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

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

这是不是我以外的人认为应该与Perl::Critic维护者一起提出的问题？

我正在为 PHP寻找相当于PerlCritic的东西。PerlCritc 是一个静态源代码分析器，它对代码进行 qritiques 并警告从未使用的变量到处理数据的不安全方式到几乎任何事情的所有内容。

PHP 是否有这样的东西可以（最好）在 IDE 之外运行，以便源代码分析可以自动化？

引用自Perl::Critic::Policy::InputOutput::ProhibitExplicitStdin

Perl 有一个名为 *ARGV 的有用的魔术文件句柄，它检查命令行，如果有任何参数，则打开并将它们作为文件读取。如果没有参数，*ARGV 的行为类似于 *STDIN。如果您想创建一个从 STDIN 读取的程序，这种行为几乎总是您想要的。这通常以以下两种等效形式之一编写：

• 它是“只是一个约定”还是有一些不使用的充分理由<STDIN>？

我觉得<STDIN>我的代码意图比使用<>or更清晰<ARGV>。

我的代码流程是这样的

perlcritic抱怨以下代码，一些运行良好的样板 DBI 东西，应该croak代替die：

所有这一切，而 die 似乎对我来说很好用。

我认为对于武士 Perl 战士来说，当事情出错时，呱呱叫声比实际死更不光彩。笑话分开

我为什么要croak代替die？

不听 Perlcritic 的建议会有什么后果？

以下 perl 代码在 PerlCritic 中生成警告（由 Activestate 提供）：

生成的警告是：

不要在列表函数中修改 $_

有关该警告的更多信息在这里

我不明白这个警告，因为我不认为我在修改 $_，尽管我想我必须这样做。有人可以向我解释一下吗？

我被告知有可能Perl::Critic在其输出中显示有问题的策略名称。但我不记得我必须做什么才能打开它。如何在 中启用此功能perlcritic.rc？

我正在尝试开始使用 Perlcritic，并且正在改进我自己的配置，忽略所有我不同意或认为不适合我的规则。

我知道我可以使用 .perlcrirticrc 文件来执行此操作，并且我可以使用该文件中的 exclude 指令来排除我不同意的策略，但要做到这一点，我需要找到该策略的名称导致我想抑制的错误。

我在任何地方都找不到 CPAN 文档中的策略列表，并且错误消息没有给出正在生成的策略的名称，所以我完全不知道应该如何生成我的排除列表。

如果有人能指出将错误映射到策略的方法，或者甚至只是指出核心中的策略列表，我将不胜感激！

我有一个脚本，我正在尝试使用 perlcritic 消除不良做法。

我的一行如下：

这给出了这个错误：在第 xxx 行第 x 列使用了两个参数“打开”。参见 PBP 第 207 页。（严重性：5）

关于如何解决它的任何想法？

评论家不接受跟随代码，严重性 4：

我收到此错误：

但是这个代码被接受，没有任何备注：

使用临时变量写我的回报真的更好，还是批评者检测到Comma used to separate statements我只是在构建和返回一个 hashref 的时间是错误的？