是否有任何良好的自动化框架在Perl中应用编码标准? [英] Are there any good automated frameworks for applying coding standards in Perl?

查看:173
本文介绍了是否有任何良好的自动化框架在Perl中应用编码标准?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道的是 Perl :: Critic



我的Google搜索导致到目前为止多次尝试没有结果。 : - (



有没有人在这里有任何建议?



任何配置Perl :: Critic的资源

解决方案

在设置配置文件方面,您是否尝试过 perlcritic --profile-proto ?这将发射到stdout所有已安装的策略及其所有选项,包括它们的默认值,以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
。 / p>

你不需要有一个perlcriticrc处理所有的代码。为要测试的每组文件创建单独的perlcriticrc文件,然后单独测试指向每个文件。例如,请查看作者在 http://perlcritic.tigris.org/source/browse/perlcritic/trunk/Perl-Critic/xt/author/ 。当运行作者测试时,有一个测试运行P :: C的所有代码,第二个测试只对策略应用额外的规则,第三个测试批评P :: C的测试。



我个人认为每个人都应该运行在残酷严重性级别,但是敲掉他们不同意的政策。 Perl ::批评家不是完全自律;甚至P :: C开发人员不同意一切Conway说。看看在Perl :: Critic本身使用的perlcriticrc文件,并搜索Perl :: Critic代码的##无评论者的实例;我现在是143。



(是的,我是Perl :: Critic开发者之一。)


One I am aware of is Perl::Critic

And my googling has resulted in no results on multiple attempts so far. :-(

Does anyone have any recommendations here?

Any resources to configure Perl::Critic as per our coding standards and run it on code base would be appreciated.

解决方案

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.)

这篇关于是否有任何良好的自动化框架在Perl中应用编码标准?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆