Vectorworks 2024に限ったことではなく、VW2023でもそれ以前でも発生していたと思う。たまにハマるのでメモしておく。
文法エラーがあると、エラーの行の下の行番号と内容が表示される、という事例。
たとえば次のコード。
スクリプトをコンパイルすると、エラーになって次のようなメッセージが表示される。文字列を期待している、という指摘だ。で、何処の？となる。
349行目がエラー、と表示されているように見えるけど、varの宣言文を見ると、GFはrealで、GRがstringとなっていた。348行目を次のように修正。
GR:=gEDIT_11;
これでコンパイルは成功。
コンパイルエラーになったら、１行前のコードも疑おう。もちろん正しい宣言文があるか、セミコロンが記述されていないかとか、関数の始まりも要チェック。
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のまま」にしておくことはそれほどコストはかからないし合理的と言えるのではないか。えっ、「コードが長くなって、あちこちでこのように書いてたら全体ではコード量が馬鹿にならない」って？
ループの回数、と言う重要なファクターを我々は設計し、実装した経緯があるのに、リファクタリングによってその経緯がわからなくなる。短い方が可読性にプラスという思い込みのために、コードの品質を落としていないだろうか。「コードは道具」という側面があるので、清書して使いにくくするものではなく、使いやすい状態にしておくほうがいいと思う。
続きはまた後ほど。