我知道的一个是Perl :: Critic

到目前为止，我进行的谷歌搜索没有得到任何结果。 :-(

有人在这里有什么建议吗？

根据我们的编码标准配置Perl :: Critic并在代码库上运行的任何资源将不胜感激。

解决方案

回答

喜欢：

• http://metacpan.org/pod/Perl::Critic
• http://www.slideshare.net/joshua.mcadams/an-introduction-to-perl-critic/

看起来像一个不错的工具！

回答

对于大多数样式标准来说，这都是愚蠢的。可以使用.perlcritic文件轻松配置perlcritic。我个人在第一级使用它，但是我禁用了一些策略。

回答

除了"自动化框架"外，我强烈推荐Damian Conway的Perl最佳实践。我不同意他提出的建议的100％，但大多数时候他都坚持不懈。

回答

Perlcritic与EPIC for Eclipse打CTRL-SHIFT-C(或者我们首选的配置快捷方式)是完美的组合，并且无论perlcritic发现什么值得抱怨的地方，代码都标有警告指示器。比记住在签入之前运行它要好得多。和正常使用perlcritic一样，它将拾取.perlcriticrc，以便我们可以自定义规则。我们将.perlcriticrc保留在版本控制中，以便每个人都获得相同的标准。

回答

在设置配置文件方面，我们是否尝试过" perlcritic --profile-proto"？这将以perlcriticrc格式发出将所有已安装策略及其所有选项及其所有描述(包括其默认值)的标准输出。保存并编辑以匹配我们想要的内容。每当我们升级Perl :: Critic时，我们可能都想再次运行此命令并与我们当前的perlcriticrc进行比较，以便可以看到对现有策略的任何更改并选择任何新策略。

关于定期运行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和
任务：： Perl ：：关键：：包括可选依赖项。

我们不需要一个perlcriticrc即可处理所有代码。为要测试的每组文件创建单独的perlcriticrc文件，然后针对每个文件创建单独的测试。例如，请访问http://perlcritic.tigris.org/source/browse/perlcritic/trunk/Perl-Critic/xt/author/，查看针对P :: C本身的作者测试。运行作者测试时，会有一个测试运行在P :: C的所有代码上，第二个测试仅对策略应用添加规则，而第三个测试则批评P :: C的测试。

我个人认为，每个人都应该在"残酷的"严重性级别上运行，但要剔除他们不同意的政策。 Perl :: Critic并不完全自我兼容；甚至P :: C开发人员也不同意Conway所说的一切。查看Perl :: Critic本身使用的perlcriticrc文件，并在Perl :: Critic代码中搜索" #no评论家"的实例。我目前计数143.

(是的，我是Perl :: Critic开发人员之一。)

回答

除了美观的最佳实践，我总是发现在单元测试套件上运行Devel :: Prof来检查测试覆盖率很有用。

回答

上面提到Devel :: Prof的帖子实际上可能意味着Devel :: Cover(以获取测试套件的代码覆盖率)。