ここ数年、else-if を書いていない。書いてはいけないとまで思っている。
以前コードレビューで 「 else-if は書かないほうがいいですよ」というコメントを書きそうになり、ふと、なぜ書いてはいけないんだろうと我に返った。
新卒 1 年目のとき「オブジェクト指向できていますか？」というスライドを読んだ。
このスライドはオブジェクト指向について少し過激に伝えていて、そのなかで「else 句を使用するな」という内容がある。else-if や switch を避け、早期 return を心がけよという話だ。
早期 return という書き方には当時、感銘を受けた覚えがある。それ以来ずっと早期 return を心がけている。
ただ、なぜ else-if を書くべきでないかは詳しく語られていない。
次に、このスライドの原典である「ThoughtWorks アンソロジー」を読んだ。
書籍には次のように書かれている。
プログラマなら誰でも if-else 構文を知っています。この構文は、ほとんどのプログラミング言語に組み込まれており、単純な条件ロジックなら誰でも簡単に理解できます。
しかし、ほとんどのプログラマは、うんざりするほどネストされた追跡 不可能な条件文や、何度もスクロールしなければ読めない case 文を見たことがあるでしょう。
さらに悪いことに、既存の条件文に単に分岐を 1つ増やすほうが、もっと適切な解決方法を考えるよりも楽なのです。また、条件文は重複の原因になることがよくあります。
else-if は誰でも簡単に書けてしまい新たな分岐を追加しやすい。分岐が増え続けると読むに耐えない状態となってしまう。else-if は楽な方法だが、コードが読みづらくなる原因のひとつである。
つまり else-if は、将来やってくる複雑さの根源になるので早いうちに芽を摘むべきということだ。
「複雑になってから else-if を使わない書き方にリファクタリングすればいいじゃん」という声が聞こえてきそうだ。実際、自分はそう思いながら読んでいた。
たしかにそれでいい場合もある。読みづらくないなら else-if のままでいい。過度にリファクタしても、作りこみのムダになりかねない。
ただ、厄介なのは「複雑になってから else-if をやめる」というルールを知らない人がコードを触るとき。「ああ、ここでは else-if を書く習慣なんだな」と思って、そのまま else-if で書き加えてしまう可能性は高い。プログラミングにそこまで慣れてない人ならなおさらそうなる。
なので、個人的には書籍のとおり最初のうちに芽を摘んでおくべきだろうと感じる。
「オブジェクト指向できていますか？」と一緒にリーダブルコードも 1 年目のときに勧められて読んでいた。
この本には早期 return に関連する内容がある。「7.5 関数から早く返す」と「7.7 ネストを浅くする」あたりだ。ネストが深くならないよう早めに return して見通しをよくしていこうという話だ。else-if を書くべきでないという内容は書かれていない。
色々とふりかえってみたが、else-if を書くなというより、早期 return を心がけよという話だった。
早期 return を心がけているうちに else-if を書く場面がなくなり、その結果 else-if は書くべきでないという意識に変わっていったのだろう。
結論として、はっきりと else-if を否定できる根拠はなかった。ただ、経験上 else-if で書かれたコードのほとんどはリファクタリングしたほうがいい状況ばかりだった。
else-if で書かれているからとすぐに否定すべきではないが、else-if は改善の余地がある目印だと考えればいいだろう。