10

数年前、私は (かなり大規模で Perl を使用することが多い) 会社のベスト プラクティス/コーディング スタイルの作成に参加しました。これは、「上級」Perl 開発者の委員会によって行われました。

コンセンサスによって行われたものと同様に、誰もが同意しない部分がありました。当たり前。

最も間違っていた部分は、多くの Perlism (C++ や Java などに存在しないコード イディオムとして大まかに定義されている) を使用しないことを強く推奨することでした。コンストラクト」。

このようなルールの主な根拠は、Perl 以外の開発者が Perl コード ベースを使用するのに非常に苦労するというものでした。ここでの仮定は、Perl のコード ジョッキーは、Perl を使用していない人よりも、全体的に (そして会社の新入社員の間でも) まれな人種であるということです。

SO がこのロジックを支持または拒否する良い議論を持っているかどうか疑問に思っていました...会社の Perl コーディング標準は硬直化しており、私が知る限り二度と改訂されることはないため、現時点では主に学術的な好奇心です。

PS 明確にするために、質問は私が指摘した文脈の中にあります.Perlだけの小規模な開発ショップの答えは、明らかに「Perlを最大限に活用する」ことです。

4

6 に答える 6

30

私は、有能な Perl プログラマーが読むことを想定してコードを書きます。私は賢くなるためにわざわざ行くことはありませんが、それを馬鹿にすることもありません。

その言語を知らない人のためにコードを書いている場合、その言語を使用するポイントのほとんどを見逃すことになります。私はしばしば、彼らがすでに知っている以上のことを学ぶことを拒否するために、人々がパーリズムを非合法化したいと思っていることに気づきます.

あなたは小さな Perl ショップにいると言っているのですから、コードが何を意味するのか理解できない場合は、コードを書いた人に尋ねるのはかなり簡単なはずです。そのようなことは、コード レビューなどで出てくるはずです。コードをレビューする定期的かつ定期的な機会があるため、誰もが言語についてさらに学び続けます。他の人が誰かのコードを見ていない状態で、あまりにも多くの時間を経過させてはなりません。彼らが会社を辞めてから 1 週間後まで待つべきではありません。

新規採用者に関しては、キーボードの前に座って、見たことのないコードベースでの生産的な作業を期待して解放する必要があると考える人がいることに、私はいつも戸惑っています。

これは Perl に限ったことではありません。これは一般的なプログラミングの問題です。ツールについて常に学習する必要があります。私が知っている大規模なショップのほとんどは、開発者が遭遇するかもしれないトリッキーなコードのビットを含め、コードベースの速度を開発者に教えるためのミニ ブートキャンプを開催しています。

于 2010-01-22T18:20:42.920 に答える
7

2 つの簡単な質問を自問します。

  • 私がこれを行っているのは、それが悪魔のように巧妙である、および/または Perl の奥義に関する私の豊富な知識を誇示しているからですか?

それは悪い考えです。しかし、

  • 私がこれを行っているのは、それが慣用的な Perl であり、Perl の明確な利点から恩恵を受けているからですか?

それからそれは良い考えです。

Java と C に文字列補間がないという理由だけで、たとえば文字列補間を拒否する正当な理由はわかりません。unless面白いものですが、サブルーチンを時折

return undef unless <something>;

悪くない。

于 2010-01-22T20:22:07.403 に答える
6

どういう意味ですか？

良い：

  • 慣用的なforループ：for(1..5) {}またはfor( @foo ) {}
  • 配列のスカラーコンテキスト評価：my $count = @items;
  • map、grepおよびsort：my %foo = map { $_->id => $_ } @objects;

制限されている場合はOK：

  • ステートメント修飾子コントロール-末尾のif、unlessなど。
    • エラートラップと早期リターンに制限します。 die "Bad juju\n" unless $foo eq 'good juju';
    • Schwernが指摘したように、もう1つの良い使用法は、デフォルト値の条件付き割り当てですmy $foo = shift; $foo = 'blarg' unless defined $foo;。この使用法は、IMOよりもクリーンですmy $foo = defined $_[0] ? shift : 'blarg';。
    • 避ける理由：チェックなどに動作を追加する必要がある場合は、大きな再フォーマットの仕事があります。IMO、ステートメントをやり直す手間は（優れたエディターでも）、いくつかの「不要な」ブロックを入力するよりも混乱を招きます。
  • プロトタイプ-のようなフィルター関数を作成するためにのみ使用しますmap。プロトタイプは、他の言語の意味での「プロトタイプ」ではなく、コンパイラのヒントです。
  • 論理演算子-いつ使用するかand、orvs 。&&とを標準化し||ます。すべてのコードは一貫している必要があります。Perl::Criticポリシーを使用して適用する場合に最適です。

避ける：

  • ローカル変数。動的スコープは非常に奇妙で、他の場所localと同じではありませlocalん。
  • パッケージ変数。悪い習慣を可能にします。グローバルに共有された状態が必要だと思われる場合は、リファクタリングしてください。それでもグローバル共有状態が必要な場合は、シングルトンを使用してください。
  • シンボルテーブルハッカリー
于 2010-01-22T18:09:55.387 に答える
2

あなたが言うように、それは数年前だったに違いありません。なぜなら、Damian Conway はここ数年間、Perl ベスト プラクティスで Perl 標準の「市場を独占」してきたからです。

私は同じように硬直化した環境で働いていました。そこでは、最新のベスト プラクティスを採用することは許可されませんでした。それは変更になるためであり、企業構造の十分に高いレベルの誰も理解していません (または理解するのに苦労する可能性があります)。 Perl と 21 世紀への移行を承認します。

テクノロジーを展開して保持しているが、専門知識を購入したり、社内でトレーニングしたりしていない企業は、トラブルを求めています。

（あなたは高度に変更管理された環境で働いていると思います-おそらく財務ですか？）

ちなみに、これについてはブライアンに同意します。

于 2010-01-23T03:21:19.820 に答える
1

Mooseは、慣例により、使用すべきではないPerl-ismの99.9％を殺すと思います：シンボルテーブルハッカー、オブジェクトの再祝福、一般的なブラックボックス違反：オブジェクトを配列またはハッシュとして扱います。素晴らしいことは、「使用しない」という機能ヒットを取得せずに、これらすべてを実行できることです。

あなたが実際に参照している「perl-isms」がミューテーター形式である場合（$ good_ideaでない限り、「悪い考え」に警告する）、、unlessそしてuntil、これらの「perlisms」はそうではないので、あなたは本当に多くの議論を持っているとは思わないperlユーザーまたは非perlユーザーのどちらにとっても読みやすさを阻害しているようです。

于 2010-01-22T17:40:35.197 に答える
0

「 Effective Perl Programming: Ways to Write Better, More Idiomatic Perl (2nd Edition)」のコピーを手に取り、それをガイドラインとして扱ってください。C や Java (またはその他の) スタイルの Perl コードとは対照的に、適切な Perl スタイルの Perl コードを作成するための優れたイディオムが多数含まれており、情報が少し詰まっています。

于 2010-08-18T20:03:46.750 に答える