はじめに
私は、これまでいくつかのPJでPHPの開発をしたり、自分でも勉強がてらアプリを作ったりしてきました。
その中で、同じPJに参画していた方から教えていただいた技術や自分でこれは心得ておきたいと思った事をまとめてみました。
また、最初にこの記事を書いたのは2018年3月ですが、半年後、1年後、さらにその先はガラリと状況が変わっている可能性もあります。
その場合、できるだけ最新の情報に更新し続けたいです。
1. バージョン
もし、これから新規でPHPで何かを作り始めるなら間違いなく7系を使った方がいいです。
5系に比べて言語としての処理速度も上がっていますし、新機能も増えています。
昔からある古いプロダクトの保守などで、どうしても5系を使い続けなければいけないPJもあると思いますが、
5系で一番新しい5.6ですら2018年内にセキュリティサポートが切れてしまうので、多少大変でも7系への移行はした方がいいのではと思います。
2. コーディング規約
PHPに関しては、素直にPSR-2に従うのが無難だと思います。
なぜかというと、PSRはLaravelなどのFWで採用されている規約のため、従っていた方がFWのソースコードを読むときにもストレスを感じなくなる気がします。
また、これは私の経験ですが今までに関わったPHPのPJはPSRの規約を採用しているところがほとんどだったので、
新しいPJに参画するときにもストレスを感じなくていいと思います。
3. IDE
個人、学校、会社等がお金を出せるのであれば、PhpStormがオススメです。
1万円弱/年くらいなので決して安くはないですが。。。
補完機能などがあるのはもちろん、PJ作成時にPHPのバージョンを指定してコード中にそのバージョンで非推奨関数があれば、取り消し線で強調してくれます。
プラグイン入れれば他のIDEでもできるかもしれないですが、PhpStormはそれをデフォルトでやってくれるので、ストレスなくできます。
ただIDE立ち上げのIndexingで少し時間がかかりますが、それだけ我慢すれば特に不便さは無いです。
4. フレームワーク(FW)
PHPはマイナーなものからメジャーなものまで多くのFWが存在していますが、
自分の経験上Laravelをオススメします!
まずはマニュアルが充実してて見やすいです。
公式マニュアルはこちら。
また、日本語マニュアルも充実してて、新しいバージョンがリリースされてから翻訳されるまでかなり速い印象です。
色々書くとLaravelの記事になってしまうので、書くとしたら別の記事にさせていただきます。
実は、今まで2記事ほどLaravel関係の記事を書いた事があるので、興味ある方は見ていただけると嬉しいです。
(あまりLaravelの良さを伝えている記事ではないですが。。。)
5. スカラー型宣言
スカラー型宣言は、7系から使えるようになった機能です。
型宣言自体は、5系時代からありましたが、7系では厳密モードにすることで関数の引数や戻り値で宣言した型以外のものをTypeError例外とすることで、
暗黙の型変換による想定外の動きを防止することができます。
ソースコードにすると以下のような形になります。
<?php
declare(strict_types=1);
class Example
{
public function calc(int $number): int
{
return $number * 10;
}
}
-
declare(strict_types=1)
:暗黙の型変換をさせず、TypeError
例外とさせるには、この宣言をする必要があります。ちょっと不便なのはこの宣言はファイルごとに宣言する必要があるので、忘れないようにする必要があります。
6. PHPCS
phpcsは、「PHP_CodeSniffer」の略で、静的コード解析ツールです。
指定したコーディング規約に違反していないかをチェックしてくれます。
こちらは、色々インストール方法があるみたいですが、前述のリンクのReadmeに記載されているcomposer
を使用するのが楽かなと思います。
実際に例を見てみましょう。
下記のコードに対してphpcs
でチェックをしてみます。
<?php
namespace App\Utilities;
class Example
{
public function hoge() {
null;
}
public function huga()
{
if (true) {
null;
}
}
}
コマンドは以下のようになります。phpcs
の後に--standard
オプションでPSR2
を指定して、その後に対象ファイルパスという感じですね。
もちろんパスはディレクトリレベルで複数のファイルを一度にチェックすることも可能です。
$ phpcs --standard=PSR2 /path/to/Example.php
さて結果を見てみましょう。
以下のように出力されました。
----------------------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 2 LINES
----------------------------------------------------------------------------------
7 | ERROR | [x] Opening brace should be on a new line
14 | ERROR | [x] Line indented incorrectly; expected at least 12 spaces, found 8
----------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------------------
Time: 333ms; Memory: 6Mb
一番左の数字は行数になります。
7行目の「Opening brace should be on a new line」は、hoge()
の後の{
は改行してくださいということです。
14行目の「Line indented incorrectly; expected at least 12 spaces, found 8」は、インデントが半角スペース12個分必要なのに8個分しかないですよ、という警告になります。
このようにメッセージで警告してくれるので分かりやすいです。
また、phpcs
をインストールした際に、同時にphpcbf
も使えるようになるのですが、これは体裁の崩れを自動で修正してくれるコマンドです。
ちなみに前述の結果で[x]
となっているもののみ自動で修正できるみたいです。
7. PHPMD
phpmdもphpcs
と同様に静的コード解析ツールです。
違いは、phpcs
は指定した規約の違反チェックをしますが、phpmd
は長すぎるプロパティ名、複雑なメソッドなどのチェックをして警告してくれます。
いわゆる冗長だったり、レガシーだったりするコードを検出してくれます。
phpmd
もcomposer
を使用してインストールする事が多いと思います。
phpcs
同様に実際に例を見ていきましょう。
下記コードに対してチェックをしてみます。
<?php
namespace App\Utilities;
class Example
{
private $hoge;
public function hogeFuga()
{
null;
}
public function piyoPiyo($a)
{
return $a * 10;
}
}
phpmd
のコマンドは以下のようになります。
$ phpmd /path/to/Example.php text codesize,controversial,design,naming,unusedcode
コマンドの説明をすると、
phpmd ファイルパス 出力形式 チェックしたいルール1,チェックしたいルール2,・・・
のようになります。
ルールはいくつかに分類されるのですが、詳しくは公式ページを参照ください。
そしてチェック結果は以下のようになります。
/path/to/Example.php:7 Avoid unused private fields such as '$hoge'.
/path/to/Example.php:14 Avoid variables with short names like $a. Configured minimum length is 3.
ファイル名:行数と警告メッセージが出力されます。
7行目は、$hoge
が宣言されているにも関わらず、使用されていません、ということです。
また、14行目は、変数名が短すぎます(最低3文字必要)、という警告になります。
これはあくまでデフォルトのルールなので、自分たちに合ったルールにカスタムすることが出来ます。
まとめ
今回書いた技術を採用してPHPで開発を進めれば、それなりの品質のプロダクトができるのではないかなと考えています。
自分一人で作るのなら、別に無秩序なものでも困らないかもしれないですが、
やはり複数人のチームでプロダクトを作っていくのが一般的だと思うので、ある程度方針を固めて意識統一した方がレガシーなコードにはなりにくいと思います。
今回は、広く浅い記事でしたが、FWに特化したりなど、もう少し狭く深い記事も書いていきたいと思っています。
また、他にもこれはイケてると思った技術を思いついたら追記していきたいと思います。