ここにあるドキュメントは古いものです。より新しいものがperldoc.jpにあります。 → perlstyle - Perl スタイルガイド

NAME

perlstyle - Perlのスタイルガイド

DESCRIPTION

プログラマーには、それぞれ自分自身の書き方に関する好みというものをがあるでしょう。けれども、その一方でプログラムを読みやすく、理解しやすく、保守しやすくするための一般的なガイドラインがあります。

最も重要なことは、常に -wオプションをつけてあなたのプログラムを実行するということです。もしそうしなければならないというのであれば、変数 $^Wを通じてコードのある特定の部分についてこれをオフにすることができます。また、あなたは常に use strictを付けて実行すべきで、そうしないのであればなぜそうしているかを知っておくべきです。use sigtrapとuse diagnosticsというプラグマも有用です。

コードレイアウトの美学に関して、唯一 Larry が強く気にかけることは、複数行に渡る BLOCK の閉じ中括弧の位置を、その構文を開始するキーワードとカラム位置を揃えるということです。この他には、それ程に強くはない好みとして:

4 カラムのインデント。
開き中括弧は、できるだけキーワードと同じ行におくようにする。さもなくば、キーワードとカラムを揃える。
複数行ブロックの中括弧の前は空ける。
1 行の BLOCK は中括弧も含めて 1 行にしてよい。
セミコロンの前には空白を入れない。
「短い」1 行の BLOCK では、セミコロンを省く。
ほとんどの演算子の両側には空白を入れる。
(ブラケットの中にある) 「複雑な」添字の両側には空白を入れる。
内容の異なる固まり(chunk)ごとに空行を入れる。
else は行替えする。
関数名と開き括弧の間に空白を入れない。
コンマのあとには空白を入れる。
長い行は (``and'' と ``or'' 以外の) 演算子のあとで改行する。
その行内でマッチする最後の括弧の後にスペースを入れる。
対応する項目は、カラムを揃えて縦に整列する。
明瞭さの妨げにならない範囲で、余分な句読点などは省く。

Larry はこれらのことに対して彼なりの理由を持っていますが、他の人が同じように考えなくても文句をいう筋合いのものではありません。

もう少し本質的なスタイルの問題も考えておくべきでしょう:

ある方法で書けるということは、その方法でやるべきだということではありません。Perl は何でもいくつかの方法でできるように設計されていますので、もっとも読みやすいものを選ぶとよいでしょう。たとえば、
```
    open(FOO,$foo) || die "Can't open $foo: $!";
```
という方が
```
    die "Can't open $foo: $!" unless open(FOO,$foo);
```
のように、文の重要なポイントを修飾子に隠してしまうよりも良いでしょう。また、
```
    print "Starting analysis\n" if $verbose;
```
の方が
```
    $verbose && print "Starting analysis\n";
```
よりも良いでしょう。使う人が -v と入力したかどうかを判定するのがポイントではないからです。
同様に、演算子にデフォルトの値が用意されているからといってそれを利用しなければならないというものではありません。デフォルトは、怠け者のシステムプログラマが“使い捨て”(one-shot)プログラムを書くためにあるのです。プログラムを読みやすくしたいと思うならば、ちゃんと引数を与えるようにしてください。
さらには、多くの場所で括弧を省くことができますが、これは決して省かなければならないということではありません:
```
    return print reverse sort num values %array;
    return print(reverse(sort num (values(%array))));
```
疑わしいときには括弧を付けるべきです。少なくとも、viで % キーを使って、跳ねまわることができます。
特に疑わしい場合でなくても、みなさんの後を引き継いでコードのメンテをする人のことを考えてあげてください。間違ったところに括弧を付けてしまうかも知れません。
ループの最初や最後で抜けられるように、妙に莫迦げた細工をしないこと。Perl では、last 演算子を用意しているので、ループの途中で抜けることができるのです。目立つように、少しばかり突き出して置けばよいのです:
```
    LINE:
        for (;;) {
            statements;
          last LINE if $foo;
            next LINE if /^#/;
            statements;
        }
```
ループラベルを付けるのを恐がってはいけません。多重のループからの脱出するためでもありますが、読みやすくするためでもあるのです。上の例を参照してください。
戻り値をただ単に捨ててしまうような void 文脈で、grep()やmap()、 `backticks` (訳注: `ls`のようにバッククォートで括った実行文のこと)を使うことは避けましょう。そういった関数はすべて戻り値を持っているのですから、それを使うべきです。戻り値に用がないのであれば、代わりにforeach()を使ったループか system()関数を使いましょう。
移植性のため、すべてのマシンでインプリメントされていない機能を使う場合には、eval の中で使ってみて調べてください。その機能がインプリメントされているバージョンやパッチレベルがわかるのであれば、 $] (English モジュールを使っているときには $PERL_VERSION) を調べて、実装されているかを見ることができます。<Config モジュールで Perl をインストールした時に、Configure プログラムで決定された値を引き出すことができます。
意味のある識別子名を使ってください。何を意味しているのかがわからなくなれば、きっと問題になるでしょう。
$gotitのような短い識別子もおそらくokですが、単語を区切るためにアンダースコア (_)を使いましょう。これは、一般的に言って $VarNamesLikeThis よりも $var_names_like_this のほうが、特に英語のネイティブスピーカーでない人にとっては、読むのが簡単です。これは VAR_NAMES_LIKE_THIS のような場合でも有効である単純な規則です。
パッケージの名前はときとしてこの規則の例外となります。Perlは integerや strictのような“プラグマ”(pragma)モジュールの名前のために、小文字のモジュール名を非公式に(informally)予約しています。他のモジュールは大文字で始め大小文字を混ぜて使うべきですが、モジュール名に対応するファイルシステム上のファイルの名前に関わる制限のために、小さなバイト数に名前を押し込めるためにアンダースコアを使わないことになるでしょう。
あなたは変数のスコープや性質を表わすのに大小文字の区別を使うのが便利であることに気がつくかもしれません。
```
    $ALL_CAPS_HERE   定数のみ (perlの内部変数とぶつかってるのに注意!)
    $Some_Caps_Here  package-wide global/static
    $no_caps_here    my() または local() による 関数スコープの変数
```
関数名、メソッド名は $obj->as_string() のようにすべて小文字にするのが最善でしょう。
名前の先頭にアンダースコアを使うことで、その変数や関数がそれが定義されているパッケージの外では使うべきでないということを表わすために使うことができます。
ごちゃごちゃした正規表現には、/x 修飾子を使って、空白を入れ、なるべく見やすくするようにしましょう。正規表現の中にスラッシュやバックスラッシュを使っている時には、区切文字にスラッシュを使うのは避けましょう。
リスト演算子に括弧を付けなければならなくなるのを避け、&&や || といった記号的な演算子の頻度を下げるために“and” や “or” という新しい演算子を使ってください。過剰な & や括弧を避けるために、サブルーチンは関数やリスト演算子として使いましょう。
何回も print() 文を繰り返すよりは、ヒアドキュメントを使ってください。

対応するものは縦に並べましょう。特に一行に収まらないくらい長い場合には。

    $IDX = $ST_MTIME;
    $IDX = $ST_ATIME       if $opt_u;
    $IDX = $ST_CTIME       if $opt_c;
    $IDX = $ST_SIZE        if $opt_s;

    mkdir $tmpdir, 0700 or die "can't mkdir $tmpdir: $!";
    chdir($tmpdir)      or die "can't chdir $tmpdir: $!";
    mkdir 'tmp',   0777 or die "can't mkdir $tmpdir/tmp: $!";

システムコールのリターンコードを常にチェックしましょう。問題を起こしたプログラム、失敗したシステムコールとその引数を含め、そして非常に重要な(何が悪かったのかという)標準のシステムエラーメッセージからなる良いエラーメッセージを STDERRに出すべきです。以下の例は、単純ではあるが十分なものの例です。
```
    opendir(D, $dir)     or die "can't opendir $dir: $!";
```
変換を行なうときに並べることでわかりやすくなるならば、並べましょう。
```
    tr [abc]
       [xyz];
```
再利用性を考えましょう。同じようなことをまたしなくてはならないかもしれないときに、一時凌ぎのスクリプトに頭を悩ませることはないでしょう。コードを一般化することを考えてください。モジュールやオブジェクトクラスを書くことを考えてください。use strict や -w を有効にして、コードの不明瞭な部分が無いようにしてください。コードを減らすことを考えてください。全体の見方を変えることも考えてください。さらに ... やめましょう。
一貫性をもって。
良識をもって。