プログラム考察：関数

かつてアセンブリ言語では、複数の箇所で実行する一連の命令群をサブルーチンとして一か所にまとめていた。サブルーチンとしてまとめることにより、プログラムサイズを減らすことができた。（代わりにサブルーチンを呼び出すコスト＝実行性能やスタックなどを犠牲にしていたけど）
これが今日の関数の始まり。
基本的には、複数の箇所で実行する処理を切りだして関数とする。

しかし、関数の意味はこれだけではない。
処理の意味（＝機能）ごとに関数にまとめることによって、プログラムの構造を把握しやすくできる。生産性の向上になるわけ。
（むかしはエディタがプアだったので、ひとつの関数の行数は４０行とか制限があったけど、今さらだよね。今は、そんな行数制限するべきではなく、分かりやすい範囲の行数にするべき。）
いまのコンパイラは優秀なので、１回しか実行されない関数であっても実行性能に影響はほとんどない。（いまどき、実行性能を考えて保守に不利なコーディングをする人も少ないだろう。ほかの所で実行性能を上げる苦労をしとけ）
まさにオブジェクト指向は、機能の意味でメソッドを作るという考えで成り立っている。

まあ、どのように関数を作ればいいかわからない人は、関数のテスト（＝モジュールテスト）をするためのMCL（日立製作所だけの用語か？）を作成するのに、条件を書き込みやすいような関数にするべき。条件が増えたら関数を分割する。
というのも、あまり大きな関数になると
→条件が多くなるとプログラムが読みにくくなる。
→読みにくいと、保守性が悪い。バグを作り込みやすくなる。
→条件が膨大だと、MCLを作り辛いし、条件網羅性を満たすためデバッガで条件をいろいろ設定しなければならないのでテストしにくい。

関数を小さくすると
→条件が少ないので関数のコードを読みやすくなる。逆に関数が増えてどこに何があるのやら。コメントを活用したり、関数名の規則を厳密にするべし。（ヘッダに関数宣言を列挙して、そこに関数の意味の概要を書いとけ）
→読みやすくなると、保守性がよくなる。修正も小さな関数単位の影響で済むかもしれない。（そのように作れば）
→条件が少ないので、MCLを作りやすい。ただし、関数ごとにMCLを作るので枚数が多くなる。（担当を分けられるね！）条件が少ないのでデバッガで設定しやすい。テストしやすい。

まあ、関数の分割をあまり細かくするのは考え物だけど、ん万Stepの関数を書くのはバカの所業だぜ。いまどきCOBOLERでもそんなのかかない（よね？）