読者です 読者をやめる 読者になる 読者になる

途中でreturn編 ちょっとりふぁくと

とりあえず、関係のないところでつっこまれたのでちょっとりふぁくと。

あー、やっぱり。予想通り「ながら」処理の典型的なのが出てきました。「ながら」処理というのは複数の事を一度に実行しようとする実装です。

「ステータスを変更する必要があるかどうか?」を判断しながら「遷移先のステータスを決め」ながら「ステータスを変更する」という。わかりやすく言えば、一輪車に乗りながら頭にボールを乗せてバランスを取りながら焼きそばを食べるという必要性がほとんど説明できないコード。

困った事にC言語系だとこれが普通なんですが、こいつが多くのメンテナンス不能なコードとバグを生み出しているフリーザ級の悪の親玉。

http://d.hatena.ne.jp/y_nakanishi/20090123/1232728337

codepad
それはそれでいいとして、
nextのStateの決定を処理するところは残る。
で、「途中でreturn」の話である

bool Person::checkNextState()
{
    bool result = false;
    if (isStand()) {
        setNextState(&standState_);
        result = true;
    } else if (isMove()) {
        setNextState(&moveState_);
        result = true;
    } else if (isJump()) {
        setNextState(&jumpState_);
        result = true;
    }
    return result;
}

は、構造上は同じになる。
複数の状態をチェックしながら、その遷移先を決めることが変だと言われたらどうしようもないが。
主題は

「ステータスを変更する必要があるかどうか?」を判断しながら「遷移先のステータスを決め」ながら「ステータスを変更する」

ではないので、とりあえず、分割をしてみた。
(固有のステートの中から、固有のステートにいきたい場合もあるが、それは書かなかった)
で、主題はステートのコードではないので、真面目に途中でreturnについて話すと、

何故に途中でreturnするのがいけないかというと、途中でreturnするということは何らかの状態が存在しているということなので、その時点でSingleResponsibilityに反していること。途中でのreturnを許すと明示化されているべき状態やシーケンスを実装に埋めて行くとことになるので「可能な限りコードでコードの説明をすべき」という、2つの良いソフトウェアを書くための基本的な法則を無視することになるから。

なのだけれど、
途中でreturnするということもまたコードでここで戻りますよ、ということを語っているわけで、
個人的には、「可能な限りコードでコードの説明をすべき」
であるならば、result=trueとreturn true;も情報量としてはたいした違いではなく、
コードとしてはresultが以降でfalseになる可能性を秘めており、他の処理が行われ可能性があるresult=trueより、
ここでtrueが確定し、他の処理もしませんよ、
ということが確定しているreturn true;
のほうが余程コードを明確に説明していると思うけれど、
そうではないんだろうか?