WordPressのコーディングスタンダードとPSR-2がかみ合わない

説明

先日パソコンのストレージを換装して開発環境を再構築。エディタのEclipseは「Neon（4.6）」から「Oxygen（4.7）」へ切り替わった。コードを書き始めるとそこはかとなく違和感があり、調べていくとPHPの「Code Style（Formatter）」が「PSR-2」に設定されていることが原因だった。

PSR-2とは

「PSR-2」はPHP-FIGによって策定されたPHPコーディングスタイルガイドである。このコーディングスタイルはWordPressの「PHP Coding Standards（以下、WordPress Standards）」と異なる部分がある。主な違いは次の通り。

コードで比較

次はPSR-2のクラス定義は以下のような感じになる（ここでは名前空間の宣言は割愛）。

<?php
class ClassName
{
    public function methodName($arg1, $arg2 = null)
    {
        if ($arg1 === $arg2) {
            // if body
        } elseif ($arg1 > $arg2) {
            // elseif body
        } else {
            // else body
        }
    }
}

上記のコードを「WordPress Standards」に合わせてみる。なおクラスやメソッドの開き括弧{はWordPressのクラス定義を参考に行末とした（これは明文化されていない）。

<?php
class Class_Name {
	public function method_name( $arg1, $arg2 = null ) {
		if ( $arg1 === $arg2 ) {
			// if body
		} elseif ( $arg1 > $arg2 ) {
			// elseif body
		} else {
			// else body
		}
	}
}

インデントの違いは一目瞭然だが、ifのような制御構造におけるスペースの使い方が異なっていることがわる。

両者に共通するルールはいくつも存在するが、開き中括弧(の後と閉じ中括弧)の前のスペースの有無が見た目の印象を大きく変えている要因といえるだろう。

実践できていなかったこと

さて今回「PSR-2」と「WordPress Standards」を見ながら、これまでなんとなく（惰性的に）やっていたことを変えていこうと思った。

1つ目は「else if」。通常、コロン構文は使っておらず、そこはかとなく「elseif」が嫌だったため、「else if」を使用していた。これにより特に問題はなかったが、「PSR-2」「WordPress Standards」とも「elseif」の使用を推奨していることを踏まえ、今後は「elseif」に切り替えたい。

2つ目は論理NOTの「!」と型キャストの後のスペース。これまでスペースを入れてこなかったが、今後は「PHP Coding Standards」に合わせてスペースを入れるようにしたい。

3つ目は次のswitch制御内で意図的に処理をスルーさせる場合の「no break」コメント。これは「PSR-2」に記載されていることだが、明示的にコメントを入れる方が他者だけでなく未来の自分もわかりやすいと思うのでぜひ実践していきたい。

4つ目はプロパティ定義の「var」。これは「PSR-2」を読んで深く反省。今後は「var」ではなくプロパティの用途に応じて「public」「protected」「private」を適切に使い分けていきたい。

今回保留したこと・まとめ

最後に「PSR-2」では「クラスのプロパティ名やメソッド名において、それが「protected」や「private」を示す意図で1字のアンダースコア_をプレフィックスを使用すべきではない」としている。こちらについては明確な理由がわからなかったため、とりあえず保留とした。世の中の「PSR-2」の採用状況はどんな感じなのだろう。