9

我知道的一个是Perl::Critic

到目前为止，我的谷歌搜索多次尝试都没有结果。:-(

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

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

4

7 回答 7

12

在设置个人资料方面，您尝试过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和 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::Critic 并不完全自律；即使是 P::C 开发人员也不同意康威所说的一切。查看 Perl::Critic 本身使用的 perlcriticrc 文件，并在 Perl::Critic 代码中搜索“## nocritic”的实例；我现在数了143。

（是的，我是 Perl::Critic 开发人员之一。）

于 2008-09-15T13:12:17.130 回答
5

大多数文体标准都有不同之处。perlcritic 可以使用.perlcritic 文件轻松配置。我个人在一级使用它，但我禁用了一些策略。

于 2008-09-09T10:41:18.370 回答
4

除了“自动化框架”，我强烈推荐 Damian Conway 的Perl Best Practices。我不同意 100% 的他的建议，但大多数时候他都在努力。

于 2008-09-10T20:40:45.657 回答
3

上面提到Devel::Prof的帖子可能真的意味着Devel::Cover（获取测试套件的代码覆盖率）。

于 2008-09-16T22:03:31.353 回答
2

像：

看起来是个不错的工具！

于 2008-09-09T10:20:42.147 回答
1

一个很好的组合是 perlcritic 与 EPIC for Eclipse - hit CTRL- SHIFT- C（或您首选的配置快捷方式），并且您的代码在 perlcritic 发现有问题的地方用警告指示器标记​​。比记得在签入前运行它要好得多。与 perlcritic 一样，它会获取您的 .perlcriticrc 以便您可以自定义规则。我们将 .perlcriticrc 保存在版本控制中，以便每个人都获得相同的标准。

于 2008-09-15T09:43:49.300 回答
0

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

于 2008-09-16T09:24:24.127 回答