2014年10月18日土曜日

コーディング規約を紐解く

コーディング規約とは、コーディングする際のルールの事です。こういう風に書きなさいという決まりごとです。これは、問題を解決するためのTipsでもあります。
では、どのようにして規約が作られていっているかを見てみることにします。

PHPコーディング規約の標準化を勧めている www.php-fig.org に参加メンバープロジェクトの統計がありますので、これを使って解説いたします。

・インデントの種類

タブ:7
スペース2つ:1
スペース4つ:14

タブはインデント作成機能そのものなのですが、エディタによってタブの幅が統一されていないのが嫌われている原因です。スペース2つ分だったり、4つ分だったりです。
そしてスペースを使ってしまう人が居るとガタガタになってしまいます。
メンドクサイから設定無しで統一できるスペースを使おうという流れが主流であります。

タブ幅の問題が無視できる身内完結型プロジェクトでしたら、タブを使ったほうが遥かに効率的です。
なのでタブ派も非常に多いと思います。
有名どころでさえ1/3もタブ利用を規約に入れていますね。

スペース2つはDelphiがそうでした。 4つだと疲れるので2つにしようということですかね。
問題点は、2つだけだとインデントが分りにくい場合があるということです。

ちなみに私は、幅4のタブ派です。 これになれるとスペース4はストレスがたまります。
スペースのプロジェクトでよくあるのはスペースの数を間違える人。統合開発環境を使わない人は必ずミスりますね。これがストレスなのです。

・1行の長さ制限(なるべくこれ以下に)

無し/未指定:2
75文字:4
80文字:6
85文字:1
100文字:1
120文字:4
150文字:1

75文字、80文字が多いのは、横幅が640ピクセルだったDOS時代の名残りです。
当時は1行80文字までしか表示できなかったので、それに慣れている人が多いということです。

120文字がいくつかあるのは、現在の状況に合わせた結果です。
120文字を表示できない環境はまず無いと言えます。
80文字は短すぎて、非常にみにくいソースとなりやすいです。
しかしあまりにも横に長すぎるのもみにくいです。
なので、見易さを考慮して120としています。

・1行の長さ制限(これ以上は禁止)

無し/未指定:13
85:4
100:3
120:2

多くの人は、状況によっては非常に長い行も許容するということですね。
臨機応変にということです。

・クラスの規則

無し:1
小文字:1
小文字とアンダーバー:1
単語1文字目大文字:19

大文字開始はクラス名だということを一目でわかるようにするための工夫です。
クラスが無かった時代は、ユーザー関数名が大文字開始というのが一般的でした。
これは標準関数ではないということを一目でわかるようにし、解析を楽にするための工夫でした。
昔は統合開発環境のような解析補助機能なんか無く人力による解析でしたからね。

・クラスの「{」を書く場所

次の行:16
同じ行:6

これはメソッドでの規則と連動していると思います。
プログラミングを長年していると、誰でも自然と次の行に書くようになります。
一目で境界がわかるようにするための工夫となります。 パラグラフと同じですね。

・定数の規則

全て大文字:22

昔から変っていない定番です。定数という事を明確にわかるようにします。

・true false nullの規則

小文字:19
大文字:3

定数なので例外なくこれも大文字って人が少なからず居ます。
しかしこれら定番の定数は大文字で書かなくても定数だと誰もがわかります。
小文字で書くほうが楽なので、
PHPStormの初期設定は何故か大文字開始というマイナー設定ですが。

・メソッド名途中の単語区切り

大文字開始:21
アンダーライン:1

クラスとの違いは、名前の1文字目は小文字開始ってだけです。
この差別で見分けやすくですね。

・メソッドの「{」を書く場所

次の行:15
同じ行:7

理由はクラスのと同じです。

・制御構造(ifなど)の「{」を書く場所

次の行:4
同じ行:18

長くやっている人は同じ行で定着しやすいです。制御構造は同じ行にしないと非常に見にくいと感じます。
まとめると、クラスとメソッド(関数)は次の行、制御構造は同じ行にしてコーディングを楽にします。
どうすれば楽にコーディング&解析できるかを工夫していくと、これにたどり着くと思います。(他のブログを見ても、ファイナルアンサーでこうなる人が多く感じます)

・制御構造の後のスペース(「if ()」 と書くか、「if()」 と書くか)

無し:2
あり:20

これの理由は忘れました。 おそらく関数ではないよってことくらいでしょうか。

・制御構造の括弧{} 省略を許容するか

許容:3
省略不可:19

本番で省略はありえないと私は感じます。 省略を許可しているプロジェクトは不具合発生率が半端ではないです。あたりまえだと思います。
後から見る/編集することを前提に、必ず{}を書く必要があります。
不具合を減らすための知恵です。
省略形は基本的にテスト等の一度使って消す物でしか使ってはいけません。
よく悩まされるのでここは強く言います。

・elseやelseif 

次の行:6
同じ行:16

おそらく、ifの「}」と同じ行に書くかどうかですよね。
制御構造の「{」の理由と連動するはずです。異なるプロジェクトもあるみたいですが。

・switch構文内のインデント(case/break)

0/1:4
1/1:4
1/2:14

0/0派の人も見たことがあります。
インデントを少なくする人の主張は、インデントが深くなってしまうのを防ぎたい。
そもそも問題になるほど深くなってしまうようなコーディングに問題があると思います。
特別な事を考えずスラスラ書ける1/2が多いですね。
例外的な書き方をなるべく減らすのも大切です。

・関数名の後のスペース

無し:22

説明不要ですね。関数は()まで含んで1つです。 制御構造とは違うのです。

・php閉じたタグ(?>)を書くか

禁止:19
書く:3

書くのは、はるかいにしえの時代からのプロジェクトで改正していない所って感じがあります。
PHP公式マニュアルにも、「省略するように」と注意書きがあります。
省略しないプロジェクトでよくある不具合は、閉じたタグの後に空行スペースが入り込んでしまい動かなくてはまるという問題です。 私も何ども経験しました。 誰だスペース入れたのは!って。

「?>」は終了タグと思ってはいけません。 html文書の開始タグです。


・改行コード

未指定:5
LF:17

大抵は未指定でも問題にならないのですが、問題になることもあるので統一したほうが良いです。
エディタによっては改行が壊れます。(改行の重複問題)
一番無難なのは、エディタをLFに設定してソース編集して、そのまま変換無しにコミットすることです。

・制御構造の頭にスペースを入れる

?:1
無し:19
入れる:2

スペースを入れるなという規約を見るのは、入れる人がいるのですね。
そういうコードは見たことが無かったのでカルチャーショックです。

・phpタグの後に空行を入れるか

?:1
無し:13
入れる:8

ばらばらだと汚らしいから統一しようという程度ですね。

・クラス/メソッド/制御構造の「{」位置  (まとめです)

次/次/次:4
次/次/同:11
次/同/同:1
同/同/同:6


以上が調査内容ですが、これはあくまで基本事項だけですね。
後はプロジェクトによってもっと細かい規約が存在するって感じでしょうか。