null判定をis_nullでしてたけど 止めた話 PHP勉強会＠東京 2024/01/24 仲見川勝人@NakMeKtt

- 仲見川 勝人（@NakMeKtt） - 職業 - Software Engineer - Mobile App, Front End, Server Side - 所属 - 株式会社ホワイトプラス - 宅配クリーニング「リネット」の開発 - Tech lead - アプリ開発G Engineering Manager 2 自己紹介

3 みなさんnullチェック どうしてますか？

1. is_null($var) 2. !isset($var) 3. $var === null 4

メリデメは3年前に@o0h_さんが書かれたこちらの記事が詳し く書かれていますので割愛 「is_null()を使うか === nullを使うか」と何気なく聞いてみたら面白かった (@o0h_) https://daisuki.nichiyoubi.land/entry/2020/12/14/010345 5

6 まず、 なんで自分のチームが nullチェックの 方法を決めたのか （決めたかったのか）

ある日のPRできたコード（イメージ）、 nullチェックとして変数を そのまま評価。 7

1. is_null($var) 2. !isset($var) 3. $var === null 4. $var <-第四の選択肢か？ 8

いいえ、この書き方は Falsy（フォルシー）※1な値か どうかで判定されてしまうため 意図通りにならない可能性があり、 適切ではありません。 ※1：Falseとして扱われる、いわゆる曖昧な比較でFalseになるやつ 9

先ほどはDateTimeのObjectなので まぁまぁ問題は起きなそう。 （善し悪しは置いておき） intだとわかりやすく問題がある。 （実際そんな書き方するか？ という疑問はいったん脇へ置き） 0を評価するとFalseになってしまうため、 No4のケースで意図通りに動かない 10

Falsyなチェックを避けきちんとnullチェックを行うために、 nullチェックの方法をチーム内で検討しADR※1としてルール化。 いくつかある方法で今回の様に意図と違う書き方をしないための 補助輪（ガイド）を設けたかった。 ※1：Architectural Decision Records アーキテクチャの決定にいたる経緯（検討、議論内容）を残し どのような判断をしたのかを記録するドキュメント 私たちはPRレビューでの揺れを低減するために今回のような複数の書き方のあるもの も含めています。 11

このときの議論ではこの辺の意見がチーム内では多くis_null()を採 用した。 - 用意されているのであればそれを使うのがよいのではないか - nullである事を評価する場合視認性がよさそう - 既存処理の都合もあり、Lintは設定出来ないので厳密な比較($var === null)ではなく曖昧に書いてしまうのが怖い（$var == null） というのが2022年頃の話。 12

13 時は流れ2023年

!is_null() が見づらいね？ 思ったよりもis_null()を反転したい機会が多かった。 PHP8へのバージョンアップタスクで曖昧な比較が消え去った。 （＝Lintが設定出来る、したとは言って居ない） と言う事で再度検討して$var !== nullを使う方針に。 コードの読みやすさ（目が滑らない）が決め手 気持ちとしてはis_not_null()が有ればそれを使いたかった 14

しかし！ nullsafe演算子のお陰でnullチェックが必要な機会は減ります！ 15

nullsafe演算子についてはPHPカンファレンス関西で話します！ nullsafe演算子を使おう〜if文地獄からの開放〜 16