我所知道的是Perl::Critic
到目前为止，我的谷歌搜索没有导致多次尝试的结果。 ： - （
有人在这里有任何建议吗？
根据我们的编码标准配置Perl :: Critic并在代码库上运行它的任何资源都将受到赞赏。
答案 0 :(得分：12)
在设置个人资料方面，您是否尝试过perlcritic --profile-proto？这将发出stdout所有已安装策略的stdout及其所有选项，包括perlcriticrc格式的两者的描述，包括其默认值。保存并编辑以匹配您想要的内容。每当您升级Perl :: Critic时，您可能希望再次运行此命令并使用当前的perlcriticrc执行diff操作，以便您可以看到对现有策略的任何更改并获取任何新策略。
在定期运行perlcritic方面，设置Test::Perl::Critic测试以及其他测试。这对新代码很有用。
对于现有代码，请改用Test::Perl::Critic::Progressive。 T :: P :: C :: Progressive将在您第一次运行时成功，但会保留违规次数;此后，如果任何计数上升，T :: P :: C :: Progressive将投诉。需要注意的一件事是当您还原源控制系统中的更改时。 （你正在使用一个，不是吗？）说我签入一个更改并运行测试，我的更改减少了P :: C违规的数量。后来，事实证明我的改变很糟糕，所以我恢复了原来的代码。由于计数减少，T :: P :: C :: Progressive测试将失败。此时最简单的方法是删除历史文件（默认位置t / .perlcritic-history）并再次运行。它应该重现你的旧计数，你可以编写新的东西再次降低它们。
Perl :: Critic有很多附带的策略，但是有很多附加的策略分发。请查看Task::Perl::Critic和 Task::Perl::Critic::IncludingOptionalDependencies。
您不需要使用单个perlcriticrc来处理所有代码。为要测试的每组文件创建单独的perlcriticrc文件，然后为每个文件指向一个单独的测试。例如，在http://perlcritic.tigris.org/source/browse/perlcritic/trunk/Perl-Critic/xt/author/查看P :: C本身的作者测试。当运行作者测试时，有一个测试运行在P :: C的所有代码上，第二个测试仅在策略上应用其他规则，第三个测试批评P :: C的测试。
我个人认为每个人都应该在“残酷”的严重程度上运行，但要淘汰他们不同意的政策。 Perl ::评论家不完全自我兼容;甚至P :: C开发人员也不同意康威所说的一切。查看Perl :: Critic本身使用的perlcriticrc文件，并在Perl :: Critic代码中搜索“## no critic”的实例;我目前数143。
（是的，我是Perl :: Critic开发人员之一。）
答案 1 :(得分：5)
大多数风格标准都有perltidy。可以使用.perlcritic file轻松配置perlcritic。我个人在第一级使用它，但我已经禁用了一些政策。
答案 2 :(得分：4)
除了“自动化框架”之外，我强烈推荐Damian Conway的 Perl最佳实践。我不同意他所建议的100％，但大部分时间他都在喋喋不休。
答案 3 :(得分：2)
喜欢：
看起来像个不错的工具！
答案 4 :(得分：2)
上面提到Devel::Prof的帖子可能真的意味着Devel::Cover（以获取测试套件的代码覆盖率）。
答案 5 :(得分：1)
一个很好的组合是针对Eclipse的EPIC的perlcritic - 点击CTRL-SHIFT-C（或您首选的配置快捷方式），并且您的代码会在perlcritic找到抱怨的地方标记警告指示器。比在记入之前记住它要好得多。和perlcritic一样，它会选择你的.perlcriticrc，这样你就可以自定义规则了。我们将.perlcriticrc保留在版本控制中，以便每个人都达到相同的标准。
答案 6 :(得分：0)
除了化妆品最佳实践外，我总是发现在我的单元测试套件上运行Devel :: Prof来检查测试覆盖率是有用的。