Perl Language
ベストプラクティス

Perl :: Criticの使用

自分やチームにとってベストプラクティスの実装を開始したい場合は、 Perl :: Criticが最適な場所です。このモジュールはDamien ConwayのPerlベストプラクティスの本をベースにしており、そこでの提案を実装するうえでかなり良い仕事をしています。

注： 私は、これらの提案であることをConway自身が述べておきます。私は、本書がほとんどすべての場合に同意しないけれども、ほとんどの場合、堅実な推論を提供することを発見しました。覚えておくべき重要なことは、どのような慣行を採用することにしても、一貫性を保つことです。コードが予測可能なほど、保守が容易になります。

perlcritic.comのブラウザからPerl :: Criticを試すこともできます。

インストール

cpan Perl::Critic

これにより、基本的なルールセットと、コマンドラインから呼び出せるperlcriticスクリプトがインストールされます。

基本的な使用法

perlcriticのCPANドキュメントには完全なドキュメントが含まれていますので、私はあなたが使い始めたときに最も一般的な使用事例に進むつもりです。基本的な使い方はファイルのperlcriticを単に呼び出すことです：

 perlcritic -1 /path/to/script.pl

perlcriticはスクリプトとモジュールの両方で動作します。 -1は、スクリプトに対して実行するルールの重大度を示します。 Perl :: Criticがあなたのコードをどのくらい選ぶかに対応する5つのレベルがあります。

-5が最も穏やかで、予期しない結果を引き起こす可能性のある危険な問題についてのみ警告します。 -1は最も残忍で、あなたのコードがきちんとしているかどうか分からないほど不平を言うでしょう。私の経験では、レベル3に準拠したコードを保つことは、あまりにも苛立ちを感じさせることなく危険から守るのに十分です。

デフォルトでは、障害が発生した理由と重大度がリストされます。

perlcritic -3 --verbose 8 /path/to/script.pl

Debugging module loaded at line 16, column 1.  You've loaded Data::Dumper, which probably shouln't be loaded in production.  (Severity: 4)
Private subroutine/method '_sub_name' declared but not used at line 58, column 1.  Eliminate dead code.  (Severity: 3)
Backtick operator used at line 230, column 37.  Use IPC::Open3 instead.  (Severity: 3)
Backtick operator used at line 327, column 22.  Use IPC::Open3 instead.  (Severity: 3)

ポリシーの表示

どのルールがトリガされているのか、perlcriticの--verboseオプションを利用することで、どのようなルールが素早く参照できるのかをすぐに知ることができます：

レベルを8に設定すると、警告を発生させたルールが表示されます。

perlcritic -3 --verbose 8 /path/to/script.pl

[Bangs::ProhibitDebuggingModules] Debugging module loaded at line 16, column 1.  (Severity: 4)
[Subroutines::ProhibitUnusedPrivateSubroutines] Private subroutine/method '_sub_name' declared but not used at line 58, column 1.  (Severity: 3)
[InputOutput::ProhibitBacktickOperators] Backtick operator used at line 230, column 37.  (Severity: 3)
[InputOutput::ProhibitBacktickOperators] Backtick operator used at line 327, column 22.  (Severity: 3)

レベル11には、ルールが存在する具体的な理由が表示されます。

perlcritic -3 --verbose 11 /path/to/script.pl

Debugging module loaded at line 16, near 'use Data::Dumper;'.
  Bangs::ProhibitDebuggingModules (Severity: 4)
    This policy prohibits loading common debugging modules like the
    Data::Dumper manpage.

    While such modules are incredibly useful during development and
    debugging, they should probably not be loaded in production use. If this
    policy is violated, it probably means you forgot to remove a `use
    Data::Dumper;' line that you had added when you were debugging.
Private subroutine/method '_svn_revisions_differ' declared but not used at line 58, near 'sub _sub_name {'.
  Subroutines::ProhibitUnusedPrivateSubroutines (Severity: 3)
    By convention Perl authors (like authors in many other languages)
    indicate private methods and variables by inserting a leading underscore
    before the identifier. This policy catches such subroutines which are
    not used in the file which declares them.

    This module defines a 'use' of a subroutine as a subroutine or method
    call to it (other than from inside the subroutine itself), a reference
    to it (i.e. `my $foo = \&_foo'), a `goto' to it outside the subroutine
    itself (i.e. `goto &_foo'), or the use of the subroutine's name as an
    even-numbered argument to `use overload'.
Backtick operator used at line 230, near 'my $filesystem_diff = join q{}, `diff $trunk_checkout $staging_checkout`;'.
  InputOutput::ProhibitBacktickOperators (Severity: 3)
    Backticks are super-convenient, especially for CGI programs, but I find
    that they make a lot of noise by filling up STDERR with messages when
    they fail. I think its better to use IPC::Open3 to trap all the output
    and let the application decide what to do with it.

        use IPC::Open3 'open3';
        $SIG{CHLD} = 'IGNORE';

        @output = `some_command`;                      #not ok

        my ($writer, $reader, $err);
        open3($writer, $reader, $err, 'some_command'); #ok;
        @output = <$reader>;  #Output here
        @errors = <$err>;     #Errors here, instead of the console
Backtick operator used at line 327, near 'my $output = `$cmd`;'.
  InputOutput::ProhibitBacktickOperators (Severity: 3)
    Backticks are super-convenient, especially for CGI programs, but I find
    that they make a lot of noise by filling up STDERR with messages when
    they fail. I think its better to use IPC::Open3 to trap all the output
    and let the application decide what to do with it.

        use IPC::Open3 'open3';
        $SIG{CHLD} = 'IGNORE';

        @output = `some_command`;                      #not ok

        my ($writer, $reader, $err);
        open3($writer, $reader, $err, 'some_command'); #ok;
        @output = <$reader>;  #Output here
        @errors = <$err>;     #Errors here, instead of the console

コードを無視する

Perl :: Criticポリシーに準拠できない場合があります。そのような場合、Perl :: Criticがそれらを無視するように、特別なコメント「 ## use critic（） 」と「 ## no critic 」をコードの周囲にラップすることができます。無視したいルールをカッコで追加するだけです（複数のカンマで区切ることができます）。

##no critic qw(InputOutput::ProhibitBacktickOperator)
my $filesystem_diff = join q{}, `diff $trunk_checkout $staging_checkout`;
## use critic

コードブロック全体をラップするか、Criticがignoreステートメントを認識しないことがあります。

## no critic (Subroutines::ProhibitExcessComplexity)
sub no_time_to_refactor_this {
    ...
}
## use critic

ドキュメントレベルで実行される特定のポリシーがあり、このように免除することはできないことに注意してください。しかし、彼らはオフにすることができます...

永続的な例外の作成

##を使用してcritic（）を使用するのはいいですが、コーディング標準を採用し始めると、特定の規則に対して永続的な例外を作成することが望ましいでしょう。これを行うには、 .perlcriticrc設定ファイルを作成します。

このファイルを使用すると、実行されているポリシーだけでなく、ポリシーの実行方法をカスタマイズすることができます。それを使用するのは、ホームディレクトリにファイルを置くのと同じくらい簡単です（Linuxでは、Windows上で同じ場所にいるかどうかは不明です）。または、-- profileオプションを使用してコマンドを実行するときに、configファイルを指定することもできます。

perlcritic -1 --profile=/path/to/.perlcriticrc /path/to/script.pl

繰り返しますが、 perlcritic CPANページにはこれらのオプションの完全なリストがあります。私は自分の設定ファイルからいくつかの例を挙げます：

基本設定を適用する：

#very very harsh
severity = 1
color-severity-medium = bold yellow
color-severity-low = yellow
color-severity-lowest = bold blue

ルールを無効にします（ポリシー名の前にダッシュを付けます）。

# do not require version control numbers
[-Miscellanea::RequireRcsKeywords]

# pod spelling is too over-zealous, disabling
[-Documentation::PodSpelling]

ルールの変更：

# do not require checking for print failure ( false positives for printing to stdout, not filehandle )
[InputOutput::RequireCheckedSyscalls]
    functions = open close

# Allow specific unused subroutines for moose builders
[Subroutines::ProhibitUnusedPrivateSubroutines]
private_name_regex = _(?!build_)\w+

結論

適切に活用されているPerl :: Criticは、採用しているベストプラクティスのポリシーにかかわらず、チームがコーディングを一貫して簡単に維持できるようにする貴重なツールです。