科学と家事とプログラミング (python を中心に)

python 温度計測 湿度計測 DS18B20 USB9097

超構造化(04) 条件分岐 vs 場合分け

条件分岐と場合分け

条件分岐という言葉には、分かれ道にさしかかって、さてどちらに進もうか?と思案 するイメージがつきまとう。その場になるまで、分岐があることにさえ気づかないし、分 岐した後もどうなるか先が見えない。「やってみるまで分からない」ということ。これは CPU の振る舞い(Conditional Jump)そのものといってもよい。たとえて言えば、地面を這 っているアリさんの視点。それに対して、場合わけ という言葉は、将来起こりうる全て の可能性を含意しているように思う。こちらも、たとえて言えば一望俯瞰的に未来を見通 す神様の視点。未来をすべて含んでしまえば、時間的な要素は排除される。計算機は、そ の場にならないと何も判断できないけれど、設計者やプログラマーの頭の中には、全ての 場合を含んだモデル/理論といったものがあるはず。それを、手続き型の言語を使って、な かば無理やり表現するから、手続きのように見えてしまう。

f:id:sken20k:20180210154545j:plain

if 文

具体的に if 文について見てみよう。if 節 (ブロック) という言葉からも部分の存在は明 らかだけれど、ある変数(フラグ)の変更/参照がブロック間にまたがっていると、部分の厳密 性がそれだけ失われてしまう。これまた当たり前と思われるかもしれないけれど、なるべ く厳密な部分全体関係がを保つことが大事なのだと思う。例えば、2つのコード断片

    /*    A    */             /*    B    */
    if (a >= 0) {             x = 0;
        x = 1;                /* n行省略 */
    } else {                  if (a >= 0) {
        x = 0;                    x = 1;
    }                         }

において、(B の n 行省略部分が x を変更しなければ)、A も B も結果は同じだけど、設 計者の頭にあるモデルをよく保存しているのは A の方だろう。「場合分け」をそのまま素 直に表していて、表やグラフで提示された仕様との対応も良いと思われる。それに対して、 B の方は、x の値の変化(時間的な推移)、つまり、処理の 流れ を追いかける必要がある。

A の場合、if 節かelse 節のどちらかで必ずx の値が書き換わるので、if の手前で x が どうなっていたかは気にしなくて良い。それに対してB の場合、if の手前のコードを確認 しないと x の値がどうなるかわからない。一番の問題は、遡る必要があるコードの範囲が すぐには分からないことだ。見通しの悪いコードは、目で追うのがつらい。意識は予測を 欲するのだ。

A は、x の値が一度確定したら変化しないという素敵な特徴も有している。これは、時 間的推移を追うのが苦手な私のような人間にとって、大変ありがたい特徴である。 さらに、if 節とelse 節の同型性を保つと、その形を見ただけで間違いを除去できる可能 性もある。全ての誤りが分かるわけではないが、中身(意味)によらず形だけから合否を予測 できるメリットは大きい。if 節に x= という行があるのに、else 節に x= という行が見当 たらなければ、何か変だと気が付くだろう。