macOSのファインダー操作。Gitのリポジトリを何処に作ったか確かめたいときがある。たとえば次のようなフォルダ構成がある。
ここでcommnad+shift+.(ピリオド）キーを押す。これは隠しファイルを表示する、というmacOSのコマンド。
これで.gitフォルダーが「denpyou-jirou」に作られていることがわかる。もとに戻すときは、もう一度commnad+shift+.(ピリオド）キーを押す。
ちなみにここに表示されている「.gitignore」ファイルはコピペで別のリポジトリに移動させることもできる。
ターミナルアプリを使って、ls -alコマンドで見てもいい。
ターミナルアプリを起動するのが面倒な方はcommnad+shift+.(ピリオド）キーがお勧め。
ループを記述するには、For、Repeat、Whileがある。たいていのループはどの構造でも書ける。どれにするか迷う。そこでマイルール：
できるだけForを使う理由の一番は、繰り返し回数の上限がループに入る前から決められていること、である。repeatやwhileでは、条件設定をミスっていると無限ループになって開発効率が悪くなる。
で、この習慣に従うと、ループの回数を事前に取得するのが当然になってくる。デバッグでこの回数を見れば、変な結果を返している場合は、まず繰り返し回数をチェックしてゼロとか意外な数値が入っていないか確認する。トレースする場合でもデバッグ中だけ繰り返し回数に小さな数字を代入してループの動きを見ることも容易だ。
ただし、何が何でもforにする、ということではないことに注意。
定型文のようにwhileを使っていて、そのコードをコピーして使う場合、ほかと同じ構造になっていると可読性がいい、のでこの場合は「どっちでもいい」ことにはならず、理由があってwhileを使う場面になる。理由が言えるのであればforじゃなくてもいいよ、ということだし、理由が言えなければforで書いてね、ということ。
プログラミングの際に、たまに自分自身に言い聞かせている言葉。使われなくなったコードを消すかどうか迷ったとき、残しておこうという気持ちを取り払おうとして、「サクッと早く消せよ」と、無駄な時間を費やしている自分に対して言う。
今使われなくなったコードが将来の要件にあっている可能性は低い。将来の自分がその時点で、この程度のプログラムはゼロから書ける、と信じよう。同じような要件であれば、2度めに新しく考え出したコードのほうが質が良いはずだし。要件が微妙に違う場合はアジャストしなくてはならないし。プログラムというのは要件が確定した時点から考え始めればよいのだ。
せっかくできた今のコードがスーパーだとか、将来同じような複雑なプログラミングがかけるのか疑問とか、捨てるのがもったいないからパラメータを調整してより汎用的な形にして残そうかとか、思うことはすべて無駄。
いつも自分に言い聞かせているのだが。。。
削除する手間もかかるので、気づいたその場で消せばいいのに。その手間を惜しんだ結果、残ってしまって産業廃棄物化しているコードもある。忘れてしまったあとで消そうとすると、またコードを追ってしまう羽目に陥る。時間が過ぎていく。
いつもやっていればプログラミング能力はアップしていく、はず。そうなったら今スーパーなコードは将来の自分には幼稚に見えるだろう。もしプログラミングをやらなくなったら、プログラミング能力は衰えていくだろう。そのときスーパーなコードは理解不可能なコードになる。産業廃棄物となって再利用などできるはずもない。
とはいえ、削除するタイミングは難しい。書いた時点ではしっかり理解しているため、産業廃棄物ではなく財産のように見える。明日以降に理解度が下がっている自分を想像できないのだ。
前回、リファクタリングのことを書いていたらいくつか書き留めておきたくなった。今回はループの話。
コードを組み立てていく時、最初からループがうまく回る保証はない。だからコーディング中は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のまま」にしておくことはそれほどコストはかからないし合理的と言えるのではないか。えっ、「コードが長くなって、あちこちでこのように書いてたら全体ではコード量が馬鹿にならない」って？
ループの回数、と言う重要なファクターを我々は設計し、実装した経緯があるのに、リファクタリングによってその経緯がわからなくなる。短い方が可読性にプラスという思い込みのために、コードの品質を落としていないだろうか。「コードは道具」という側面があるので、清書して使いにくくするものではなく、使いやすい状態にしておくほうがいいと思う。
続きはまた後ほど。
「WEB+DB PRESS vol.127」（以下、wdp127）にリファクタリングの話があったので読んでみたら良かった。
https://gihyo.jp/magazine/wdpress/archive/2022/vol127
知らない単語が出てきたのでメモしておく。
□ 凝集度（cohesion）
□ 結合度（coupling）
調べてみると、語源は1979年あたりにヨードンが提唱していたらしい。
□ DRY（Don’t Repeat Yourself）
コードの最適化、なんでもDRYというルールがあるそうだ。
プログラミングしていると、同じようなコードを何度も書くとき、共通化できるのでは？と考える。あちこちに書いておくと、あとでそこに修正が生じた場合にあちこち直さなくてはならないため不便だし、処理が同じならモジュール化すべきだという考えだ。
wdp127では凝集度について、論理的凝集は避ける、ようなことが書いてある。要はフラグを使った関数内分岐を避けよ、という意味と理解した。ウチでは同じような意味で「多機能関数はダメ」というルールがある。
結合度については値は引数で渡す、ようなことが書いてある。要はグローバル変数は避けよ、という意味と理解した。ウチでは「関数の中はローカル変数だけを使う」と「グローバル的な変数にはゲッターセッターを用意して関数を介して取得する」というルールがある。ただし例外として、画面に一覧を表示する際のフォームオブジェクトはグローバル参照をしていいというルールもある。画面に表示する情報についてゲッターセッターをすべて用意するのはあまりにも面倒だ。フォームオブジェクトは名前付のルールでわかるようにしている。
ウチでは上記のほかに、
forやifの構造が３つ以上出現する場合は、さらなるモジュール化を検討せよ、という意味だ。
仕様がケース分岐しているのであればコードも分岐している、のがフツーだ。入り口から分岐させて、中に共通処理を見つけたら共通モジュール化する、のが良い。
できるだけ１行で書く、というコードはダメ。if文の中に関数を記述したり、引数に関数を記述するのはわかりやすいNGだ。デバッグする時にたとえばforループが何回回るのかは重要な要素だ。上手くいかないときは0回の場合が多い。これをデバッグするには繰り返し回数を見れば良いのだが、大体はなんかの関数の戻り値である。これをfor($i;1;myFunc())のように書いてしまうとmyFunc()の戻り値を見たくなる。$count:=myFunc()とか記述して$countの値を見ることになる。それなら最初からそういうコードにしておけば良い。
上記はソース内部の記述だが、表面的な仕様でもデバッグに便利な機能を実装しよう。あるテーブルの中身が見たいような機能は言われなくても作ってしまう。デバッグでよく使うツールであればプログラマは便利になる。そのままリリースして、ユーザに「削除して」と言われてから「隠す」ようにすればよい。
まだ語り尽くせないので、また思いついたら続きを書く。。。