if("".equals(ほにゃらら))はぬるぽ怖い病の名残

雑記 技術ネタ

前やってたところでも良くやっていた。オブジェクトじゃなくて定数を先に書くと云々。まあ、そこではnullと空文字は区別しなさいという掟がありましたので、先に空文字を判定していただけではありますが。

Javaで「if(stringVariable.equals(""))」と記述したとします。「stringVariableという文字列変数が何もない文字列であるときは」という意味のif文です。このif文は，もう少しうまい方法で記述可能です。それは次のどれでしょう？

http://itpro.nikkeibp.co.jp/article/COLUMN/20081125/319810/

で正解が「if("".equals(stringVariable))」なんだけど、それは「うまい方法」ではないよね。あくまであるコーディングルールがあるとき、それを守るための一手段に過ぎないわけだ。
案の定ツッコミが。

3のコードはたまに見かけるけど、こういうコードが広がると困る。場合によるけど、これは一般的に「改良」じゃなくて「改悪」だろうね。

"".equals(stringVariable) は改悪だろう - まちゅダイアリー(2008-11-30)

まあ確かに。

クラスやメソッドを作るときに重要なのは、インタフェースを明確にすること。実装は簡単に変えられるけど、インタフェースはなかなか変えられない。「stringVariable に null を許容する」というインタフェースにしたいんだろうけど、変更後のコードからはそれがハッキリとは読み取れない。

"".equals(stringVariable) は改悪だろう - まちゅダイアリー(2008-11-30)

僕のやってたプロジェクトでの大原則は「他人は信じない」であって、インターフェースでnullを許容しないというお約束はなんかのバグで入るはずのところで入らなかったら、とか最悪ケースを想定していくと100%ありえないとは言えないからちゃんとハンドリングしましょうって感じだったんだよね。nullと空文字を同義に扱えるところはこれだけでスルー出来るし、そうじゃなければ先に間違えてstringVariable.equals("")しちゃうとぬるぽが出るというのを回避できる。もちろんnullチェックもすることが大前提。
nullと空文字チェックは同じif文でOR判定していたら両方テストすることが面倒なので全パス網羅ならわざわざnullを設定するテストはしないこともある。そんな中nullPointerExceptionが結合テスト以降に出ようものなら大騒ぎになっちゃうしね。
問題先送り感は無きにしも非ず。
こうして書いてみると変な省力化の為にバグ発見機会を減らしているようにも見えるね。というわけで、全然うまい方法ではないのでありました。ぬるぽよりも本当に怖いのはぬるぽを隠蔽する心なのでありました。