寄せては返す繰り返し…… (1997.Jan.6)

    Select Case iCond	'(1)
	Case ISFILE
            fmMyOne![ctDisplayYear].Enabled = True
            fmMyOne![ctDisplayMonth].Enabled = False
            fmMyOne![ctDisplayDate].Enabled = False
	Case ISDIR
            fmMyOne![ctDisplayYear].Enabled = False
            fmMyOne![ctDisplayMonth].Enabled = True
            fmMyOne![ctDisplayDate].Enabled = False
	...

　こういうのが延々と続く場合、どんなものでしょう。下のように書き換えるというのは？

    Select Case iCond	'(2)
	Case ISFILE
	    ChgCtrls(True, False, False)
	Case ISDIR
	    ChgCtrls(False, True, False)
	...

	...
	Case ISNONE
            fmMyOne![ctDisplayYear].Enabled = False
            fmMyOne![ctDisplayYears].Enabled = False
            fmMyOne![ctDisplayMonth].Enabled = False
            fmMyOne![ctDisplayDate].Enabled = True
	...

　という変則部分がぽろっと混じっていてもそうと気付かないのではないか？
という懸念です(変更時の不具合、バグの元)。
　また、同じような事を何度も繰り返して記述しているのも気になる点。(1)のようなコードをどこかで再利用する時、殆どの行を訂正しないと使えないではありませんか？(2)のようにサブルーチンにしておけばそいつを書き換えるだけで済むのに。
　1つの変数に付き1回の変更で済むのと、Case節の数だけ掛け算した回数の変更が必要の書き方、どっちが綺麗？

　(2)の書き方の場合、サブルーチン・コールのコストが余分にかかるとか、何をしているのかサブルーチンの中を見ないと分からない、という反論もあるでしょう。
　でもそれよりも何よりも全体の構造が見やすい方が後々楽なはず。それに

	┌───────────────────────────┐
	│変更があった時の手間をできるだけ小さくするコーディング│
	└───────────────────────────┘

　って鉄則だと思うのだが……。

　基本的には、Const MAXVALUE = 100とか書いて、後は100と書かずにMAXVALUEを使いましょう。というのと同じ思想なんだけど。

＃自分の仕事を自分で増やしててもしょうがないと思うのよね

補足：(蛇足かもしれない)

　ところで、あるプログラムの長さが2倍になった時、(潜在的な)バグの量も2倍になるのでしょうか？
　私はそうは思わない。長さ2倍というなら、プログラムのある部分にかけられる(設計時間)コストは短いプログラムの1/2倍になるという事になる。
　これだけでバグの量が4倍になっても不思議はない。

　更にはそのある部分を見ている時に考慮しなければならない部分、これも(長さが)2倍になっているはず。という事はその部分の検証に必要なコストも2倍と言う理屈です。
　　　　　　 　　　 ・　　　　　　　　　　　 ・
　すなわち、1/2になったプログラマのコスト(時間的資源)で2倍のプログラムのコスト(長さ)を相手にしなければならない。
　結果として2倍の長さのプログラムには8倍の量のバグが潜む可能性がある、という訳です。

　短いプログラムは、コンピュータ資源の為ではなく、プログラマの為に必要なのです。