今さらながらPHP開発環境でコーディング規約やコードチェックに関するツール群を整えたいと思い立ち、静的解析ツールからvimプラグインまで一式取り揃えてみることにした – PHP_CodeSniffer編

PHPの開発であろうが何の言語であろうが、基本的に私はターミナル上でvimを開いてコードを書く。もちろんSyntasticによるシンタックスハイライトなどは導入しているが、コードそのもののチェックに関するプラグインやツールは導入していなかった。

インストールする理由

商業プログラマを古くからやっていたとしても、ある開発環境やグループ、プロジェクトなどからずっと抜け出せないでいると、その開発環境が普通のものとなり、そのままのスタイルでの開発が継続していく。
もちろんプロジェクトにも終わりはあって、別のプロジェクトに転換されることもある。
けれど、部署が同じ、会社が同じなどであれば、多くの場合は似たような開発環境のまま、新しいことやトレンドを知ることもなく過ぎていく…。

私は現在、幸か不幸か、出向して客先で働く身であるため、さまざまな開発スタイルに触れることができる。
今回関わったプロジェクトでは、phpunitを使ったりPRレビューでPHPのコーディング規約の判例などを指摘されたりということがあり、刺激はあった。
が、振り返って当該プロジェクトのソースコードを見ると、そのレビューの成果などはみられず、判例であったはずのコーディングスタイルが異なるスタイルで書かれていたり、調べてみたPSR-2などのPHPフレームワーク開発チームが相互に関わって規格化しているコーディング規約などのカケラなど見つからないどころか、バラバラのスタイルが散りばめられていた。

これでは意味がない。
せめて、私が主体で関わるプロジェクトのときには、こうした事態は避けなければならない。
たとえば、pushする時点で強制的にコーディング規約に適合したフォーマットに整形されるとか、誰もが個人の感覚や慣れで行う実装を極力避けることで統一された読みやすいコードになっていくと思う。

強制的に実施するかどうかはさておき、そうしたツール類があれば、コーディング時にも有用ではあると思うので、今回PHPについて考えさせられたということでPHPでそうしたコーディングサポートツールを探してみた。

インストールするもの

いろいろ調べた結果、今回導入するものは以下の3種類のツール。
ただし本記事ではPHP CodeSnifferのみに絞る。残りはあとで記事を書く予定である。

実は調べている過程でPHP CodeSnifferはチェックのみという記事を見かけたのでPHP Coding Standards Fixerをインストールしようかと思ったが、PHP CodeSnifferにphpcbfコマンドという自動修正ツールが登場しているので、これを使用することにする。

  • PHP CodeSniffer … コーディング規約チェッカー
  • PHP Mess Detector … 混乱性検出。バグ可能性、複雑すぐる式、未使用パラメータ、メソッド、プロパティなどの検出、準最適化
  • Phan … 静的解析ツール。型チェックなど

これらを導入するのに、Composerの導入は欠かせない。
すでに導入済みの人もいるだろうし、私も自分のMacBook Proにも一応インストールしてあったらしいのだが、古いし(selfupdateもできるけど)、記憶も新たに最初からやり直してみたい。

また、これらは単独でも使用可能だが、私はコーディングエディタにvimを頑なに使い続けているので、vimプラグインからの使用を前提とする。

Composerがインストールされていない場合は、あらかじめインストールをしておく必要がある。

インストール環境

前回も書いたが、インストールするにあたって使用する環境を記載しておく。
私はMacBook Proを使っているが(私がなぜMacを使っているかはここを読まれたい)、Linux/FreeBSDなどのUNIX系OSにも通じるところがある(macOSは優れたGUI環境を持つUNIXシステムだと思っている)。

  • macOS High Sierra (10.13)
  • Terminal (OS標準)
    • 他のUNIX系OSならお気に入りのターミナルエミュレータを使用すればよいだろう。
    • ちなみにFreeBSDを日々使っていた時代の私は(xterm(kterm) –> rxvt –> target=”_blank”>mltermと乗り換えてきた。
  • cURLもしくはwget (cURLはデフォルトでシステムインストール済み、wgetはHomeBrewかMacPortsで要インストール)
    • curl 7.56.1 (x86_64-apple-darwin17.0.0) libcurl/7.56.1 OpenSSL/1.0.2l zlib/1.2.11
    • GNU Wget 1.19.2 built on darwin17.0.0.
  • vim
    • プログラミングやテキストファイルの編集に使うエディタがあれば問題はないが、vim使いならvimプラグインをインストールするのでvimは欠かせない。
  • PHP7系。PhanがPHP7 requiredなので、5系ではなく7系をインストール済みであること。私は7.1系をインストールしていたので、このままこれを使う。ちなみに本記事でインストールするPHP CodeSnifferのrequirementはPHP 5.4.0以降である。
    • PHP 7.1.7 (cli) (built: Jul 15 2017 18:08:09) ( NTS )

あと使っても使わなくても問題はないが、私はTerminalで必ずtmuxを動かしている。以前はscreenを使っていたが、tmuxのほうがはるかに便利なので数年前に乗り換えた。
tmuxのインストールはHomeBrewかMacPortsで可能だ。おそらく本家サイトからソースのtarballをダウンロードして手動インストールもできるだろう。ただしlibeventなど依存関係のあるライブラリがインストールされているかどうかを確認する必要がある。
Linuxならyumやapt-get、FreeBSDならports、NetBSDならpkgsrcなどでインストールできるだろう。

  • tmux 2.6

PHP CodeSniffer

PHP、JavaScript、CSSのトークナイザー(字句解析器)であるphpcsスクリプトと、標準違反のコードを自動修正するphpcbfスクリプトの2つから成るコーディング規約チェッカーである。
composerを1回実行すると、ホームディレクトリ直下(cd ~/)に、.composerというディレクトリが自動生成される。
この中にはcomposerが使用するキャッシュファイルのディレクトリなどの実行したユーザのデータが保存されていく。
ここにbinディレクトリを作成し、この中にコマンドを保存していく。あるいは、ホームディレクトリにすでにPATHを設定した実行ファイル保存ディレクトリを持つ人は、そちらでもよいだろう。

環境変数PATHにこのディレクトリが設定されていない場合は、sh/bash系なら.profileや.bashrcに、csh系なら.cshrcにPATHを通しておく必要がある。

設定したらsourceコマンドで環境変数を再設定する。

curlコマンドでphpcsをダウンロードする。phpcs.pharはPHPアーカイブファイルで、このままで実行形式を保っている。

余談だが、GitHubにあるREADME.mdでは、pearやcomposerからのインストール方法も指定されている。どういう方法でインストールするかは環境や趣味によるだろうから、ここでは参考程度にとどめておきたい。curlはmacOSではデフォルトインストールされているコマンドなので、本記事ではそちらを採用した。
なおcomposer経由でインストールするとローカルの場合は~/.composer/vendor/bin配下にインストールされるので、PATH環境変数の設定などを確認すること。詳細はInstallation(英語)を確認されたい。

phpcs.pharは「php phpcs.phar」としても実行できるPHPスクリプトだが、単体で実行可能なバイナリファイルである。

なので、ファイル名変更で拡張子を外し、chmodで実行可能に設定すれば、通常のスクリプトと同様のスタイルで実行できる。

csh系ならrehashを叩いておくほうがいいだろう。
コマンドが実行できるかどうか、確認してみる。Usageが表示されれば問題ない。

同様にして、phpcbfコマンドも作業する。

こちらも実行してヘルプが出ればOKだろう。

phpcsコマンドを使ってコードチェック

vimプラグインの前に、コマンドラインで実際に使ってみたい。
こんなクソコードを、まずは用意してみる。
コードの内容はまったく意味を成していないので、そこは考えないように。あくまでもコーディング規約テストなので適当に書いている。
みなさんも、これに限らず普段から先輩後輩同僚が書きなぐっているクソコードなどを手元に用意されたい(違)。

いや、我ながらこれはまったくクソコードだな(笑)。自分だったら許すけど(許さない)、他人だったらぶん殴りものである。
さて、実行自体は簡単で、ファイル名を指定すればいい。

「FOUND 17 ERRORS AFFECTINGS 12 LINES」なので、12行中に17のエラー。いや、こりゃひどい(笑)
左から順に、行数、種別、エラー内容である。
エラー内容の先頭に[ ]や[x]があるが、[x]についてはphpcfbコマンドで修正可能なものを示している。[ ]のエラーは手動で調整するしかない。

phpcfbコマンドを使って自動修正(可能なものに限る)

ということで、phpcfbコマンドで自動的に[x]部分を修正してもらうことにする。

12エラーは修正され、なお5エラーが残されていることがわかる。5エラーとは、自動修正できなかった[ ]の表示のエラーになる。
どのように修正されたのか、diffを取ってみる。

ちゃんと整形してくれているし、コーディング規約的な処理もしてくれているようだ。
ただPSR-2ではcaseはswitchより1つインデントを下げるはずだったのだが、phpcbfコマンドの処理では下がっていないようだ。
とはいえ、ある程度の処理はなされている。
何が残っているかというと、最初にphpcsコマンドで[ ]に属されていたエラーである。
クラス定数を強制的に全大文字にしないのは影響が大きいから処理しないのはわかるけれど、if文の「if(…)」の空白を、識別しながら調整しないのは意外ではあった。

ということで、がんがん修正して、以下のような適切なコードにした。

phpcsによるチェック結果は…

エラーなし。何もメッセージが出ない状態になった。

オプション

オプションはいくつか用意されているので、適宜することで挙動を変更できる。
特に、PSR-2コーディング規約でのチェックはしたいところである。
この挙動を設定するには、phpcsコマンドで–standardオプションで以下のように指定すればよい。なお、デフォルトのコーディング規約ではPEARが使われている。PEARのコーディング規約だと、switch-case文のインデントは特に設定されていないためチェックされていなかったようだ。

他に使えるコーディング規約は、以下のようにエラーを吐かせると確認できる。

コーディング規約が変わったため、さきほどPEARの規約で通過したものが、のきなみエラーになった。

かなりの数が自動処理で整形できそうなので、助かる。実行してみよう。

1つ残ったので確認してみる。

case文のbreakなしの場合はfall-throughコメントをつけよといっている。
自動処理されないのは、バグなのか意図したものなのかが自動判定できないからだろう。
修正したソースは、こんな感じである。

ということで、これを対処してチェックをしてみよう。

通過した。
このときの、PEARとのdiffは、こんな感じである。
PSR-2の規約であるswitch文の中のcaseが1つインデントが下がるというのが自動処理されている。

その他オプション

その他にもオプションが多数用意されている。
詳細はUsageAdvanced Usageを確認されたい。

コメントを残す

メールアドレスが公開されることはありません。