PHP で empty() を使うことを避けてみる

PHP には empty() という便利な関数がありますが、empty() はよく理解して使用しないと意図しないバグを生む原因になります。
( empty() は厳密には関数ではなく言語構造ですが便宜上関数と呼びます。 )

よく言われる話ですが、改めてまとめてみたいと思います。

なぜ empty() は安全なコーディングを妨げるか

通常 PHP は未定義の変数を使用しようとすると「そんな変数ないよ」と警告を表示してくれますが、empty() や isset() には未定義の変数に対して使用しても警告がされないという特別な性質があり、変数名のタイプミスに気がつけなくなってしまいます。

例えば以下のようなケースです。

$fruits = array('apple', 'orange');
if (empty($fruts)) {
    echo 'これは空配列です';
}

これを実行すると $fruits が空配列 ではない にも関わらず「これは空配列です」と出力されてしまいます。empty() に渡す変数名の途中の i が抜けておりタイプミスしているからです。

また、公式マニュアルの PHP 型の比較表 のページを見ると分かりますが、空文字や 0 の場合など、empty() は多くのパターンで true を返してしまします。判定の基準が緩い関数のため、よく理解した上で使用しないと意図しないバグを生んでしまうリスクがあるということです。

ではどうするか

empty() を使用したくなったとき、なぜ使用したいのかを改めて考えてみるといいと思います。

その気になれば empty() を全く使わずにコーディングすることも可能です。
まずは empty() を使用しなくても済むかどうかを検討してみることは良いことです。

変数が null かどうかを調べたい場合

if ($var === null)if (is_null($var)) などの方法であれば純粋に変数が null かどうかだけを調べられるので安全です。

変数が空配列かどうかを調べたい場合

if (is_array($var) && !$var) などで調べられます。

PHP 5.4.0 以降の場合はシンプルに if ($var === []) で調べられるのでおすすめです。[]array() の短縮記法です。

変数が未定義かどうかを調べたい場合

事前に変数を定義するよう心がけてコーディングすれば、大抵の場面で未定義かどうかを調べなくても済むはずです。

どうしても未定義かどうかを調べたい場合は empty() より isset() を使用するほうが安全だと思います。ただし isset() を使用した場合であっても変数名のタイプミスに気がつけなくなる危険性があることは認識しておいた方がいいです。

それでも empty() を使いたい場合

色々 empty() を使わずに済ます方法を書いてきましたが、それでもなんとなく NG な値かどうかを調べたい場合 empty() は便利ですよね。

ですがちょっと待ってください。そんなときでも Boolean への強制変換を使えば empty() と全く同じチェックをすることが可能です。
PHP 型の比較表 を見ると empty() と Boolean への強制変換 if ($var) の結果は完全に対になっていることが分かります。

つまり if (empty($var) === !$var) は常に成立するということです。
念のため調べてみます。

<?php
$vars = [
    'TRUE' => TRUE,
    'FALSE' => FALSE,
    '1' => 1,
    '0' => 0,
    '-1' => -1,
    '"1"' => "1",
    '"0"' => "0",
    '"-1"' => "-1",
    'NULL' => NULL,
    'array()' => array(),
    '"php"' => "php",
    '""' => "",
];
foreach ($vars as $label => $var) {
    $result = (empty($var) === !$var) ? 'TRUE' : 'FALSE';
    echo sprintf("%s: %s\n", $label, $result);
}

これを実行した結果 は以下になったので間違いなさそうです。

TRUE: TRUE
FALSE: TRUE
1: TRUE
0: TRUE
-1: TRUE
"1": TRUE
"0": TRUE
"-1": TRUE
NULL: TRUE
array(): TRUE
"php": TRUE
"": TRUE

緩くチェックできることは PHP の良いところでもあるので PHP 型の比較表 とにらめっこしつつ活用していくといいと思います。

2018/02/18 10:17 追記:

「何故まともな静的解析ツール無しにコーディングをするのが危険なのか」というタイトルに書き直した方が良いとのコメントを頂きましたが、いま私が使用している PhpStorm や phpmd だと empty($undef) としても検出できないのですよね。

実際に typo したコードが静的解析やコードレビューをすり抜けてしまい痛い目を見たことがあるのでこの記事を書きました。ただ「そのために言語機能を制約してコーディングするのもどうなの」というのもごもっともな話だと思います。プロジェクト内で方向性があればそれに従えばいいと思います。

そもそも未定義の変数に対して empty() を使うことは言語として想定されている使われ方なので検出できる静的解析ツールも少ないのかなと思うのですよね。静的解析方面にあまり詳しくないのですがそこら辺どうなのでしょう。

CakePHP4.0 時代への展望とこれまでの振り返り

2015年に CakePHP3.0 がリリースされたことは記憶に新しいですが、先日 CakePHP の Core Developer の @mark_story 氏により CakePHP4.0 時代への展望とこれまでの歩みの振り返りがスライドとして公開されていた ので、内容を要約してみたいと思います。

※ 以下の内容は自分が CakePHP を触っていて感じたことを元に補足している内容も含まれますのでニュアンスが異なる部分もあるかもしれません。

2.x – 3.00 アップデートの振り返り

  • 3.0.0 はとても大規模で困難なアップデートだった
  • PHP7 対応に伴うモダン化
    • フレームワークのインストール方法が composer になった
    • コアコード・モデル周りの大幅な改修
      • 連想配列地獄からの脱却・オブジェクト化
      • モデルクラスが Table と Entity クラスに分離された
  • 2.x もまだメンテンナンスされている
    • CakePHP2.7 で PHP7 にも対応した

現行版の 3.2.x – 3.3.x について

  • getter / setter 分離のため移行中の段階 (詳細は後述)
  • Middleware 対応 (PSR-7互換)
    • Request / Response の構築処理に任意の処理を挟み込める
    • PSR-7 対応に伴う Request & Response オブジェクトの不変化
      • with から始まるメソッド名のメソッドは新しいインスタンスを返す
<?php
// $response オブジェクトの内容は変わらない
$response->withHeader('X-yes', 'yes');

// 戻り値に変更が反映された状態で clone instance が返ってくるので
// もし変更したい場合は代入する。
$response = $response->withHeader('X-yes', 'yes');

3.5 で提供される新機能

  • 新しいミドルウェアの提供
    • CSRF
    • Cookies
    • Authentication
  • ルーティング設定とミドルウェアの紐付けが可能に

3.6 について

  • 4.0 リリースに向けたバージョンになる
  • 3.6 未満と下位互換性は保たれる

4.0 はどんな感じになる?

  • ベースはあくまで 3.x のまま
  • PHP7.1 以上の環境が必須に ( ! )
  • 全ての非推奨メソッドの削除
    • getter と setter の両方を兼ねたメソッドも削除される

進められている getter / setter 分離対応について

より簡単なインターフェースにしてコードの複雑さを軽減することが目的。

これまで:

  • Entity::errors()

これから:

  • Entity::getErrors()
  • Entity::setErrors()

リリース予定日は?

まだ未定だが 2017年末 〜 2018年初頭になりそう。

所感

CakePHP3 はかなり大掛かりなアップデートでしたが、CakePHP4 は PHP7.1 以上が要求されること以外は比較的シンプルなアップデートになるのではないでしょうか。

近年のモダン PHP の流れを汲みつつ堅実に進化していっているなという印象を受けました。

最近の PHP フレームワークのトレンドを見ていると Laravel に押され気味な感はありますが、CakePHP も古株のフレームワークとして安心感のあるフレームワークであることは今後も変わらないと思います。がんばれ CakePHP。