16

最近、自分のコードでPerl::Criticをもっと頻繁に使い始めることにしました。Perl でのプログラミングを 7 年近く行った後、私は長い間、ほとんどの Perl のベスト プラクティスに慣れてきましたが、常に改善の余地があることを知っています。しかし、私を悩ませていることの 1 つは、Perl::Criticがサブルーチン用に @_ をアンパックする方法を気に入らないという事実です。例として：

sub my_way_to_unpack {
    my $variable1 = shift @_;
    my $variable2 = shift @_;

    my $result = $variable1 + $variable2;
    return $result;
}

これは私が常に行ってきた方法であり、PerlMonks と Stack Overflow の両方で議論されているように、必ずしも悪いことでもありません。

上記のコード スニペットを次のように変更すると...

sub perl_critics_way_to_unpack {
    my ($variable1, $variable2) = @_;

    my $result = $variable1 + $variable2;
    return $result;
}

...も機能しますが、読みにくいと思います。また、Damian Conway の著書Perl Best Practicesも読んだことがありますが、 Perl::Critic@_が暗示しているように、直接使用を避けるという彼の提案に、私の推奨する展開方法がどのように該当するのか、よくわかりません。私は常に、コンウェイが次のような意地悪について話しているという印象を受けてきました。

sub not_unpacking {
    my $result = $_[0] + $_[1];
    return $result;
}

上記の例は下手で読みにくいので、私はこれを製品コードに書くことを考えたことはありません。

要するに、なぜPerl::Criticは私の好みのやり方が悪いと考えるのですか? シフトを使って開梱する私は本当に凶悪な犯罪を犯していますか?

これは、私以外の人がPerl::Criticのメンテナーと共に育てるべきだと考えるものでしょうか?

4

5 に答える 5

11

簡単な答えは、ここでは Perl::Critic が PBP に従っていないということです。この本では、shift イディオムが受け入れられるだけでなく、場合によっては実際に好まれると明示的に述べています。

于 2010-02-16T19:15:54.703 に答える
9

ポリシーについては、Running perlcriticwith で説明しています。--verbose 11ただし、これらの説明のいずれにも当てはまらないようです。

常に @_ 最初に 1 行目の近くで展開します
'sub xxx{ my $aaa= shift; 私の ($bbb,$ccc) = @_;}'.
  Subroutines::RequireArgUnpacking (重大度: 4)
    引数を展開する代わりに `@_' を直接使用するサブルーチン
    ローカル変数には、まず 2 つの大きな問題があります。まず、彼らは非常に難しいです
    読む。代わりに番号で変数を参照する場合
    名前からすれば、アセンブラ コードを書いているのと同じかもしれません。2 番目の「@_」
    元の変数へのエイリアスが含まれています! 内容を変更する場合
    `@_' エントリの場合、変数を自分の
    サブルーチン。例えば：

       サブ print_local_var_plus_one {
           私 ($var) = @_;
           ++$var; を印刷します。
       }
       サブ print_var_plus_one {
           ++$_[0] を印刷します。
       }

       私の $x = 2;
       print_local_var_plus_one($x); # "3" と表示されますが、$x は 2 のままです
       print_var_plus_one($x); # "3" を出力し、$x は 3 になりました!
       $x を印刷します。# "3" を表示

    これは不気味な遠隔操作であり、デバッグが非常に困難です。
    意図的ではなく、十分に文書化されていません (「chop」や「chomp」のように)。

    通常の委任イディオムには例外があります
    `$object->SUPER::something( @_ )'. `SUPER::' と `NEXT::' だけが
    (これは設定可能ですが) 認識され、
    デリゲートは `( @_ )' のみで構成する必要があります。
于 2010-02-16T18:47:35.820 に答える
8

Perl のベスト プラクティスにある多くの内容は、何が最もよく見えるか、または最も簡単に操作できるかについての 1 人の意見にすぎないことを覚えておくことが重要です。別の方法で実行しても問題ありません。ダミアンは、本の紹介テキストで同じことを言っています。すべてがそうであると言っているわけではありません-- そこには絶対に不可欠なものがたくさんあります:strictたとえば、 を使用します。

したがって、コードを作成するときは、自分のベスト プラクティスを自分で決める必要があります。PBP を使用することは、他の何よりも良い出発点です。次に、自分の基準に一貫性を保ちます。

私は PBP のほとんどのものに従おうとしますが、ダミアンは私の冷たく死んでいる指先からこじ開けると、私のサブルーチン引数shifts と私のes を手に入れることができます。unless

Critic に関しては、適用するポリシーを選択でき、まだ存在しない場合は独自のポリシーを作成することもできます。

于 2010-02-16T18:46:28.770 に答える
3

場合によっては、Perl::Critic は PBP ガイドラインを正確に強制することができないため、Conway のガイドラインの精神に一致させようとする近似を強制することがあります。そして、私たちが PBP を誤解したり、誤って適用したりする可能性は十分にあります。正しくない臭いを見つけた場合は、バグ レポートを bug-perl-critic@rt.cpan.org にメールしてください。すぐに調査します。

ありがとう、

-ジェフ

于 2010-02-17T04:24:16.320 に答える
0

本当に必要でない場合は、一般的にシフトを避けるべきだと思います!

次のようなコードに遭遇しました：

sub way {
  my $file = shift;
  if (!$file) {
    $file = 'newfile';
  }
  my $target = shift;
  my $options = shift;
}

このコードで何かを変更し始めると、誤ってシフトの順序を変更したり、シフトをスキップしたりして、すべてがうまくいかない可能性が高くなります。さらに、読みにくいです-サブのすべてのパラメーターが実際に表示されているかどうかを確認できないため、下のいくつかの行はどこかで別のシフトである可能性があります...そして、間にいくつかの正規表現を使用すると、 $_ の内容を置き換える可能性があります奇妙なことが起こり始めます...

解凍 my (...) = @_ を使用する直接的な利点は、 (...) の部分をコピーして、メソッドを呼び出す場所に貼り付けて、適切な署名を付けることができることです:)同じ変数を使用することもできます-事前に名前を付けて、変更する必要はありません!

シフトは、リストの長さが動的で、その要素を一度に 1 つずつ処理する場合、または最初の要素のないリストが明示的に必要な場合のリスト操作を意味すると思います。ただし、リスト全体を x パラメーターに割り当てたいだけの場合は、コードで my (...) = @_; と指定する必要があります。誰も不思議に思う必要はありません。

于 2014-01-24T15:01:53.413 に答える