perlstyle - Perl スタイルガイド
プログラマは、もちろん人それぞれ、フォーマットには好みがあるでしょう; しかし、いくつかのガイドラインに従うことによって、プログラムの可読性や 保守性をあげることができます。
もっとも重要なことは、あなたのコード全てで strict と warnings を使うことです; さもなければその理由を理解しておくべきです。 no warnings や no strict を使用してコードの 一部だけで警告を明示的にオフにすることができ、 またこれによって無効にしたい warnings や strict の特定の機能を制限できます。 -w フラグと $^W 変数はこの目的のために使うべきではありません; これらはコアや CPAN のモジュールのような、あなたが使っているけれども 自分で書いていないコードに影響を与えるからです。
コードレイアウトの美観に関しては、Larry が強く気にかけているのはたった一つ、 複数行の BLOCK の閉じ中かっこは、その構造を開始したキーワードと同じ位置に なくてはならないということだけです。 それは別として、そこまで強くはない彼の好みは以下の通りです:
4 カラムのインデント。
可能なら、開始中かっことキーワードを同一行に; そうでなければ、開始を そろえる。
複数行 BLOCK の開始中かっこの前にスペース。
1 行の BLOCK は中かっこも含め、1 行で。
セミコロンの前に空白なし。
"短い" 1 行 BLOCK ではセミコロンを省略。
ほとんどの演算子の前後にはスペース。
"複雑な"代入(ブラケット内)の前後にはスペース。
異なることをするチャンクの間には空行。
else をくっつけない。
関数名と開始カッコの間にはスペースなし。
カンマの後ろにはスペース。
長い行は、演算子の後ろで改行する(and と or を除く)。
行の最後のカッコの後ろにスペース。
対応する要素の開始位置をそろえる。
冗長な表現は、わかりにくくならない限りは省略する。
Larry にはこれらそれぞれを好む理由がありますが、彼以外の人がこれとまったく 同じである必要はないといっています。
他に、より重要なスタイルの問題を示します:
何かをある方法で できる からといって、そう すべき とは限りません。 Perl は一つのことを様々な方法でできるように設計されていますから、より 読みやすいものを選ぶように心がけてください。 たとえば、
open(my $fh, '<', $foo) || die "Can't open $foo: $!";というのは以下のものより良いです:
die "Can't open $foo: $!" unless open(my $fh, '<', $foo);なぜなら、2 つ目では、この文の主要部が修飾子に隠れてしまっています。 逆に、
print "Starting analysis\n" if $verbose;というのは以下のものより良いです:
$verbose && print "Starting analysis\n";この文の主要部は、ユーザが -v をタイプしたかどうか ではないからです。
同様に、ある演算子がデフォルト引数を想定しているからといって、その デフォルトを使わなくてはならないということにはなりません。 このデフォルト値があるのは、怠惰なシステムプログラマが、一発プログラムを 書くときのためにあります。 プログラムを読みやすくするには、引数を省略しないようにしましょう。
同様に、多くの場所でカッコを省略 できます が、以下のように 省略しすぎることは控えるべきでしょう:
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;
}ループのラベルは積極的に使いましょう -- 可読性をあげるのと共に、多段階の ループ抜け出しもできるようになります。 先ほどの例を見てください。
grep() (や map())、また `逆クォート` を無効コンテキスト、つまり 返り値を無視する文で使用しないでください。 これらの関数はすべて返り値を持っていますから、それを使用してください。 いらないのであれば、foreach() ループや system() 関数を 使用してください。
ポータビリティのために、すべてのマシンで実装されていないかもしれない機能を 使用する際は、それを eval で囲って、失敗するかどうかチェックしてください。 ある機能が、どのバージョンやパッチレベルで実装されているか知っている 場合には、$] (English モジュールでは、$PERL_VERSION) を チェックすることもできます。 Config モジュールを使えば、Perl インストール時の Configure プログラムに よって決定された値を調べることができます。
ニーモニックな識別子を選んでください。 そのニーモニックが何を意味するか思い出せなければ、問題です。
$gotit のような短い識別子なら ok ですが、より長い識別子の単語を 区切るにはアンダースコアを使用してください。 一般的には、とくに英語のネイティブスピーカーでない人にとっては、 $var_names_like_this の方が $VarNamesLikeThis より読みやすいです。 このルールは VAR_NAMES_LIKE_THIS についても同様に当てはまります。
パッケージ名は、このルールの例外になることがあります。 Perl は小文字のモジュール名を、integer や strict のような"プラグマ" モジュールのために予約しています。 その他のモジュールは大文字からはじめて、小文字を混ぜて使用すべきですが、 アンダースコアは使用しません; プリミティブなファイルシステムでは、 モジュール名をファイルとして表現する際に、バイト数の制限があるためです。
変数のスコープや性質を表現するのに、大文字小文字を使うと便利でしょう。 たとえば:
$ALL_CAPS_HERE 定数のみ (perl 変数との衝突に注意!)
$Some_Caps_Here パッケージワイドなグローバル/スタティック変数
$no_caps_here 関数スコープの my(),local()変数関数とメソッドの名前はすべて小文字だとベストです。 例えば、$obj->as_string()。
先頭にアンダースコアをつけることによって、変数や関数を定義したパッケージ外で 使用すべきでないことを示すことができます。
ほんとにごちゃごちゃな正規表現を使う場合には、/x や /xx 修飾子を 使用してスペースをいれ、ごみみたいにならないようにしてください。 正規表現内にスラッシュやバックスラッシュがあるときには、デリミタに スラッシュを使わないように。
新しい and と or 演算子を使用し、リスト演算子のカッコがたくさんに なったり、&& や || が大量発生するのを避けてください。 サブルーチンは、関数やリスト演算子であるかのように扱い、アンパサンドや カッコが大量発生するのを避けてください。
print() 文を繰り返さず、ヒアドキュメントを使用してください。
対応するものの開始位置はそろえてください、とくに、1行におさまらないものに 関して。
$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(my $dh, $dir) or die "can't opendir $dir: $!";見やすくなる場合には、tr の開始位置をそろえてください。
tr [abc]
[xyz];再利用性を考慮しましょう。 同じことをあとでやるかもしれないときに、脳の力を一発のプログラムで 無駄にする必要はありますか? コードの一般化を考慮し、モジュールやオブジェクトクラスを書くことを 考慮しましょう。 コードが use strict と use warnings が有効でも きちんと動くか考慮しましょう。 コードを捨て去ることも考慮しましょう。 世界の見方を変えることを考慮しましょう。 他にも……ああ、もういいや。
あなたのコードを文書化して、一貫した方法で Pod フォーマットを使うように 努力してください。 以下は広く想定されている慣習です:
関数名、変数名、モジュール名(およびより一般的には、ファイルハンドルや 特定の値のような、コードの一部と考えられるもの)には C<> を 使ってください。 関数名は、function() のように、名前の後ろにかっこを付けると より読みやすくなると考えられています。
cat や grep のようなコマンド名には B<> を使ってください。
ファイル名には F<> か C<> を使ってください。 F<> はファイル名のための唯一の Pod コードであるべきですが、 ほとんどの Pod フォーマッタはこれをイタリック体で表示するため、 Unix と Windows でパスに使われるスラッシュや逆スラッシュが読みにくいです; C<> はよりよく表示されます。
つねに一貫性を。
つねに素敵に。