「あ!問題の論理に、結果が含まれていることなどは絶対にありえません。問題に結果(答え)が書かれてるならば、もはやそれは問題でもなんでもなく、単なる答えになってしまいます。「いえ、完全に間違った方向性ですね。無意識についそう考えてしまっていました。」セキヤをなじることに飽きたのか、サクラは少し調子をゆるめた。これはダサいプログラマーの悪い癖なのよ。『フローは不要』なのに、フローを書く癖が抜けないのね。あなたのダサいコードのフローチャートを見てみましょう。→(結果)nであるとか、とにかくいたるところで『結果』を計算しているの。「あーおっしゃるとおりです。問題の論理にはありもしない『結果』を何度も何度も計算させながらループを回すというフローとして設計されている。念の為だけど、私のクールなやり方でも実行環境は私が感知しない、する必要もない裏で計算しているし、実行効率の問題を言ってるんじゃないわよ。コードの書き方としてダサいと言ってるの。「もちろんわかります。「こういう、問題の論理とは一切関係もなく、フローの中で何度も計算されて刻々と値が変化して、フローの制御に組み込まれてしまっているsとかnみたいな変数のことを状態変数と呼ぶの。こんな、問題の論理とはまるで関係ない分際で、刻々と変化するような状態変数なんてものはなくしてしまいなさい。論理を設計する上で邪魔だわ。フローがバグの元凶であるのと同様に、状態変数もバグの元凶よ。「たしかに、フローがあれば状態変数も必ずありますね。手順を分割するな、論理を分割せよ「こういう結果を小出しにしながらフローを回すのは何故か?というと、ダサいプログラマーは手順を分割しようとしているからよ。「『様々な問題を抱えた家』があるわよね?1匠に玄関を直させる⇒結果(プチAfter)『なんということでしょう』。2匠に台所を直させる⇒結果(プチAfter)『なんということでしょう』。3匠に階段を直させる⇒結果(プチAfter)『なんということでしょう』。・・・このように、手順を分割して逐一結果を小出しにしながら実行するのをプログラミングだと思いこんでいるのね。だいたいこんな小出し小出しにAfterを見せられる番組なんて面白くもなんとも無いわ!」サクラは解説しながら、またイライラしはじめたらしい。「確かに、自分のこと考えればしっくりと来ます。いうか、これ以外の考え方なんてしたことがありませんでした。僕はダサくて愚かです。」サクラのイラツキを察したセキヤは殊更に反省した素振りを従順にアピールする。それに対してクールなプログラマーは論理を分割しようとしているの。何度も言ってるわよね?論理の最小単位である関数という論理操作を自在に組み合わせて論理を設計していくって。