MGLは読みやすいのか？

1) 一つのルーチンは、理解可能な範囲でなるべく大きくする。

実はこれに近いことを意識してコーディングしている。
明確に理由を説明できなければ、関数にはしない。 明確な理由とは...

• インターフェイスとして適切である。
  というのは、もちろん理由だが、なぜインターフェイスとして適切であるか 自分なりに説明できるということにこだわっている.. と思う。

• 理解可能でないと思われるぐらい複雑だから
  というのも理由かも知れないが、コードの長さでは 判断しない。 どちらかというと ネストの深さ。ただしそれも それほど単純じゃなくて、 ネストが深くなりすぎるようだったら いろいろ ... goto 文を使ってでも .. 工夫して、それでも 深くなりすぎる ようだったら 関数化を考える。
  深くなりすぎる という判断はわりと単純。80 カラムに収まるかどうか。

• 同じコードが複数回出て来るから
  というのも 理由だったりする。ある程度の規模(3行以上とか) でまったく同じ ものを、2 回以上 コピペで書くのは かなりイヤだったりする。そういうときに 関数化を考える。

2) 層になるべく分けない。

これは、 なぜインターフェイスとして適切であるかをよく考えるわけだから、 自然とそうなってしまう。

3) 外部のモジュールとの相互作用が少ないように、一つのモジュールはなるべく 大きくする。

これも、上のように作っていくと 自然とそうなる。

ただし、それは作ったときの話。改造を加えていくと、改造自体の 中で 相互作用が少ないように考えるので、全体としては、見通しが悪くなる 傾向がある。そして次の改造や 読むときの障害になってくる。

だいたいは、ある程度までは許容しておいて、 実際に障害だと思えるようなところに来たときに、 コードの組み変えをして、見通しを良くするようなことをする。

MGL2 ではどうだったかというと、なんかそういうことをやった覚えがあるんだが ... いまは思いだせない。

4) goto等を積極的に使い、なるべく一つの意味のまとまりを短い範囲のコード におさえる。ただし、goto の飛び先は、出来たら前後2画面以内程度 (合計5画面程度)におさえ、ラベルはわかりやすい物を用いる。

逆説的だけど、 構造化プログラミングが普及した結果、goto 文をあえて使う目的は、保守性や可読性 を上げる 以外にあり得ない... と思う。

cvs にある MGL2 の全ソースを grep したら goto 文は、141 個も使っていたが、 その使い方を分類してみると。

       o ネストを減らすため、リトライを goto で書く。
       o エラー処理で 関数から抜けるときの後始末。

この2つに集約されているみたい。ラベルも retry とか out1, out2 .. とか err1, err2 ... とかそんなものばかり。

上のような使い方に限定すれば、飛び先を見る必要もなく、 離れていても問題ないはず。

5) 部分的にしか呼ばれない関数を極力避けるために、なるべくインラインで 展開する事が出来るものは関数化しないで直接書き、if と while のネストを 深くする。(ただし、外部での変数を記憶にとどめておける程度の範囲で)

... これはどういうことを言っているんだろうか?

• ある関数を呼んでいて、その関数は別の関数を呼んでいる.. みていくと やたらネストが深いんだけども やっていることは 実は単純だった
  みたいなことかなぁ。

新たにものを作るときには、こういう風には作らないのが普通じゃないか と思うんだが

• 別々に設計されたものをつなぎ合わせる
• 設計時に想定していなかった改造を重ねた。

みたいな ことで、そういうものが出来上がってしまうんじゃないかと...

6. ローカル変数を増やす事で関数化が防げるなら積極的にローカル変数を増やす (ただし記憶可能な範囲で)

これも 5 とおんなじで、最初から グローバル変数を多用するような コードは作らない... はず。

改造を加えていくとき、改造自体の 中で 相互作用が少ないように考えると、グローバル変数を多用したり、 関数化 ってのが出て来て そうなっちゃうんじゃないか。

これについて MGL2 では、どうか...

(つづく)