Short cut: [Prev] [Up] [Next] [Return to Top]
墓穴編 (1997.Aug.02)
読んで分かるプログラム。
例えば：
If IsError(sDate) Then '(1)
と
If ChkError(sDate) Then '(2)
どっちが見てすぐに分かるだろうか？
これは(1)の方が分かりやすいと思う。VBにはIsXX()という関数があるから、それから挙動が類推できるからである。
(2)だとTrueの時にエラーがあったのか、それとも無かったのか判断できない。大体、(2)は呼び出し元に確実に戻るのか？エラーの時にメッセージを出すのか出さないのか？エラーのリカバリ処理は要、不要？分からない事だらけ。
どっちも似たり寄ったりだと言われればその通りだが。所詮名前、されど名前である。
でも、
iErc = IsErrors(sMsg) + 3 '(3)
てな行があったりすると最悪。普通のIsXX()の挙動と違うIsXX()を作ってしまうと他人には何がどうなのか類推不能になる。
If IsNotValid(iTime) Then '(4)
というのも良くない。「xxでない時True」とか「xxがFalseだったらTrue」という関数、時として何も考えないで作ってしまうが、後で：
If Not IsNotValid(iTime2) Then '(5)
てな行を書く羽目になって面食らう。
…人間、意外にもろいもので、「否定の否定は単なる肯定」の理解が瞬時にはできない。冒頭で出した「エラーの時にTrue」なんてのも同様。嘘だと思うならやってみることだ。
プログラム作っているうちに混乱するから。まして後からのメンテナンス時には、もろに逆条件で分岐するようにコーディングしたりする。
経験者は語る(笑)←俺だけだったりして(^^;
TrueにはOKとか問題なしという明るいイメージがあり、Falseには拒否とか失敗という暗いイメージがある。そういうことだ。
プログラムは冷徹な論理で動く。でもプログラマは人で感情で動く。感性を大切にしないとね。
大事なのは「そういう名前の場合は全てそうなってます。」と断言できる事。「多分、」とか「ほとんど、」では意味がない。「と、思う。」ではいけない。「例外ありません。」と言える自信と実績が必要。←言うだけなら誰でもできるからね
関数とか変数の名前付け、こういう名前はこういう意味。そうきっちり作ってあれば誰が後から見ても変更するのが楽なのである。
似たような名前だけど、そっちはメッセージが出ます。こっちはステータスが戻りません。あ、それは戻ってこない場合が……。これではたまらない。
一度自分で「こういう場合はこういう名前」とルールを決めたら、少なくともそのプログラム内では絶対に守り通すべき。
1つでも例外があると、後でプログラムを読む時の信頼感が随分下がるものである。
理想論？確かに。現実は甘くない。だが、例外は例外。どうしても通常の名前付けに反するような関数になるなら、例外な名前を付ければ済む。
後からの変更で、その関数を呼び出している所が100も200もあったって同じ。断固として名前を変更する方が良いだろう。
更に後、「どうしてこいつだけ例外なの？」と気付いた瞬間、名前付けされた他の全ても疑いの目で見られるからだ。
VBの予約語にたどり着いたら、それ以上の追求は普通しないでしょ？ユーザ関数でも、こういう名前ならこういう処理だと分かれば深く追求しないで済む。しかし1つでも例外があったりしたら全部見直さないと信用できなくなるって事。
そうそう。変数名に付いて。Cマガジンで連載しているある人の意見。「forのカウンタなどの使い捨て変数に妙に重々しい名前、例えばCountとか付けられると一体これにはどんな凄い意味があるのかと考えてしまう。そんなものはiで良い。逆にグローバル変数にiとかあったりするといやだ。」
Short cut: [Prev] [Up] [Next] [Return to Top]