前回、リファクタリングのことを書いていたらいくつか書き留めておきたくなった。今回はループの話。

コードを組み立てていく時、最初からループがうまく回る保証はない。だからコーディング中はfor文に繰り返す回数を与えて、その数をデバッガーで見たり、アラートやログ出力して確認することになる。たとえば次のようなコードでは$sizeOfAryに何が入っているか、プログラマなら興味があるだろう。

//code A	xxxは配列
C_LONGINT($i;$sizeOfAry)
$sizeOfAry:=size of array(xxx)
for ($i;1;$sizeOfAry)
	...
end for

昔やっていたのが、上のように書いて動作検証した後で、次のようにリファクタリングすることだった。

//code B
C_LONGINT($i)
for ($i;1;size of array(xxx))
	...
end for

これでコードが一行減って、ローカル変数が１つ減って、読みやすくなった、と思ってた時期があった。散らかってたのを片付けました、、下書きを清書しました、という感覚。

．．．？　多分、そうじゃないよね。

何らかの不具合が原因でこのコードを「後で」見ることになった場合、実行環境が変わったり、データの仕様が変わったり、未配慮の状況に遭遇しているかもしれない。そのとき最初に見たいのはfor文が想定通りに回っているかではないだろうか。つまり元のコードの$sizeOfAryに何が入っているか、だ。それで値の中身を見るためにcode Bにコードを追加したりして、つまりはcode Aに近い形に修正し直す、ことになる。

あーあ、最初からcode Aの状態にしておいてくれればよかったのに。ってね。

回数をアラートに表示するとか、繰り返す内容をログ出力したり、$sizeOfAryに小さな値を代入して少ないループでテストするとか、ローカル変数に取得しておくとデバッグ時に都合が良い。だからデバッグしやすい「code Aのまま」にしておくことはそれほどコストはかからないし合理的と言えるのではないか。えっ、「コードが長くなって、あちこちでこのように書いてたら全体ではコード量が馬鹿にならない」って？

だから「やっていることの分だけコードはあるのだ」の原則を思い出そう。

ループの回数、と言う重要なファクターを我々は設計し、実装した経緯があるのに、リファクタリングによってその経緯がわからなくなる。短い方が可読性にプラスという思い込みのために、コードの品質を落としていないだろうか。「コードは道具」という側面があるので、清書して使いにくくするものではなく、使いやすい状態にしておくほうがいいと思う。

続きはまた後ほど。