在 Perl 中应用编码标准有什么好的自动化框架吗？
我知道的一个是 Perl::Critic
我的谷歌搜索结果没有迄今为止多次尝试的结果。 :-(
这里有人有什么建议吗？
如果有任何资源可以根据我们的编码标准配置 Perl::Critic 并在代码库上运行它，我们将不胜感激。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
一个很好的组合是 perlcritic 与 EPIC for Eclipse - 点击 CTRL-SHIFT-C （或您首选的配置快捷键），您的代码就会被标记无论 perlcritic 发现什么值得抱怨的地方，都有警告指示器。 比记住在签入之前运行它要好得多。 与 perlcritic 一样，它会获取您的 .perlcriticrc 以便您可以自定义规则。 我们将 .perlcriticrc 保留在版本控制中，以便每个人都获得相同的标准。
A nice combination is perlcritic with EPIC for Eclipse - hit CTRL-SHIFT-C (or your preferred configured shortcut) and your code is marked up with warning indicators wherever perlcritic has found something to complain about. Much nicer than remembering to run it before checkin. And as normal with perlcritic, it will pick up your .perlcriticrc so you can customise the rules. We keep our .perlcriticrc in version control so everyone gets the same standards.
除了外观最佳实践之外，我总是发现在我的单元测试套件上运行 Devel::Prof 来检查测试覆盖率很有用。
In addition to the cosmetic best practices, I always find it useful to run Devel::Prof on my unit test suite to check test coverage.
上面提到的帖子 Devel::Prof 可能真正意味着 Devel::Cover （获取测试套件的代码覆盖率）。
The post above mentioning Devel::Prof probably really means Devel::Cover (to get the code coverage of a test suite).
例如：
看起来是一个不错的工具！
Like:
Looks like a nice tool!
除了“自动化框架”之外，我还强烈推荐 Damian Conway 的Perl 最佳实践。 我并不百分百同意他的建议，但大多数时候他都是直言不讳的。
In addition to 'automated frameworks', I highly recommend Damian Conway's Perl Best Practices. I don't agree with 100% of what he suggests, but most of the time he's bang on.
大多数风格标准都有 perltidy。 perlcritic 可以使用 .perlcritic 轻松配置文件。 我个人在第一级使用它，但我禁用了一些策略。
There is perltidy for most stylistic standards. perlcritic can be easily configured using a .perlcritic file. I personally use the it at level one, but I've disabled a few policies.
在设置配置文件方面，您尝试过
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::Critic::包括可选依赖项。
您不需要让一个 perlcriticrc 处理您的所有代码。 为要测试的每组文件创建单独的 perlcriticrc 文件，然后创建指向每个文件的单独测试。 例如，请查看作者对 P::C 本身的测试 http://perlcritic.tigris.org/source/browse/perlcritic/trunk/Perl-Critic/xt/author/。 当运行作者测试时，有一个测试运行 P::C 的所有代码，第二个测试仅对策略应用附加规则，第三个测试批评 P::C 的测试。
我个人认为，每个人都应该以“残酷”的严厉程度来竞选，但淘汰他们不同意的政策。 Perl::Critic 并不完全符合自我要求； 甚至 P::C 开发人员也不同意 Conway 所说的一切。 查看 Perl::Critic 本身使用的 perlcriticrc 文件，并在 Perl::Critic 代码中搜索“## no Criteria”的实例； 我现在数了一下，有143个。
（是的，我是 Perl::Critic 开发人员之一。）
In terms of setting up a profile, have you tried
perlcritic --profile-proto? This will emit to stdout all of your installed policies with all their options with descriptions of both, including their default values, in perlcriticrc format. Save and edit to match what you want. Whenever you upgrade Perl::Critic, you may want to run this command again and do a diff with your current perlcriticrc so you can see any changes to existing policies and pick up any new ones.In terms of running perlcritic regularly, set up a Test::Perl::Critic test along with the rest of your tests. This is good for new code.
For your existing code, use Test::Perl::Critic::Progressive instead. T::P::C::Progressive will succeed the first time you run it, but will save counts on the number of violations; thereafter, T::P::C::Progressive will complain if any of the counts go up. One thing to look out for is when you revert changes in your source control system. (You are using one, aren't you?) Say I check in a change and run tests and my changes reduce the number of P::C violations. Later, it turns out my change was bad, so I revert to the old code. The T::P::C::Progressive test will fail due to the reduced counts. The easiest thing to do at this point is to just delete the history file (default location t/.perlcritic-history) and run again. It should reproduce your old counts and you can write new stuff to bring them down again.
Perl::Critic has a lot of policies that ship with it, but there are a bunch of add-on distributions of policies. Have a look at Task::Perl::Critic and
Task::Perl::Critic::IncludingOptionalDependencies.
You don't need to have a single perlcriticrc handle all your code. Create separate perlcriticrc files for each set of files you want to test and then a separate test that points to each one. For an example, have a look at the author tests for P::C itself at http://perlcritic.tigris.org/source/browse/perlcritic/trunk/Perl-Critic/xt/author/. When author tests are run, there's a test that runs over all the code of P::C, a second test that applies additional rules just on the policies, and a third one that criticizes P::C's tests.
I personally think that everyone should run at the "brutal" severity level, but knock out the policies that they don't agree with. Perl::Critic isn't entirely self compliant; even the P::C developers don't agree with everything Conway says. Look at the perlcriticrc files used on Perl::Critic itself and search the Perl::Critic code for instances of "## no critic"; I count 143 at present.
(Yes, I'm one of the Perl::Critic developers.)