VBA

給料日

今月から給与カット無しの給料に戻ります。考え方によっては労せず給与アップになるんでしょうが、それは間違った見方をしています。 でも元に戻ってもこんなものか… がっくし… 頑張る気力はとうに吹き飛びました。やる気を出すために火を付けてくださいなと言っても、会社がなくなるくらいの勢いで火を付けてくれないと、もうだめっす。

だめだめプログラミング

他の人が作った何個かのプログラムを寄せ集めて、使いやすいように僕が1つにまとめたプログラムがあるのだが、ここ3年程度、想定したものを定型通りに使う分にはほとんど問題なく、想定していない希な使い方をすると、予想外の妙な動作をするという何とも知れない状態なので、久しぶりに中身を見てみることにした。
すると、そこには私が書いた部分も含めて_だめだめなプログラミングの典型_とも言える跡がいっぱい残っていた。VBAだととかくこういうプログラムになりがちという典型であるのだが、とりあえず僕がブラックボックスとして使っていた部分に問題があることまでデバッガで突き詰めた。しかし何度デバッガでトレースしても_実に動作が読めない_。何をしようとしているのかまるで分からないのである。自戒を込めて、かいつまんで原因をあげるとこんなところか。
一つ一つの関数・プロシジャが長い。
全体の見通しが付かないくらい長大。まぁ処理上しょうがない部分はあるし、気が付くと自分もこういう関数やプロシジャを書く場合が多いので、人のことは言えない。 ただし僕の場合は長くなっても単機能なものにまとめるようにしている。
長いプロシジャが線形に続く
メインのプロシジャから、関数A, 関数B, …を呼び出すのではなく、A関数の処理が終わったらB関数を呼び出し、B関数の処理が終わったらC関数を呼び出す。最終的に最後に呼んだ関数で処理が終わる。(実際には僕がくっつけたときに元の関数に戻るようにはしたのだが…)
GOTO文の嵐
条件分岐の際にGOTO文を乱発する。デバッガで追いかけても処理がどうなっているのか追い切れない。当然意図しない2重処理をしているのかも知れない。(少なくともソースからはどういう処理をしているか読み解けない。)
Global変数の多用とLocal変数との名前の衝突
安易にGlobal変数を用いたので、変数スコープの関係で意図しない値が入っている(入っていない)場合が多い。(今回のプログラムの場合、Loopの終点判定がかなり怪しい。)
Doc/Viewが分離されていない
Doc/Viewが分離されていないから、アルゴリズムが表示周りの雑多な処理に埋没してさらに理解不能となっている。
ブラックボックスな部分をリファクタリングしようにも、全体に影響が出そうなので手が出せなさそう。こまったものだ。最初にこの不具合に遭遇したときも同じ結論だったが、結合前のプログラムまで遡って、駄目な部分は捨てて、すべて再設計というのが望ましいと言う結果だ。構造化プログラミングの教科書に書いてありそうな事ばかりなのだが、なかなか実践できないものなのね。(実践すべく頑張らねば。)

今日のVBAとの闘い

前回のVBAとの闘いでは、Cで言うところのsscanf()みたいな関数がないので、テキストファイルからの入力は不便じゃのうという話だった。普通のExcelのユーザ(VBAを使いこなしている人はすでに_普通の人ではないと言う意見はあるが_)は、CSVなファイルもExcelで開いてから、VBA側でセルを参照して値を取り出すのかな? 僕はそういうデータ構造を考えないプログラムを書く趣味を持ち合わせていません。
今回の闘いは、まともにCollection系のライブラリが欲しいという話。ちょっと考えてみると、文字列をKey、構造体をValueとするHashを使えれば、一発でおしまいという話だったのだが、VBAやVBっていまいちCollection系のデータ構造がまるでないので、いかんせんいろいろと貧弱すぎだなぁと思うのよね。結局配列で非常に安直な実装にしたのだが、どうにかならんもんかね。VBプログラマはデータ構造なんて考えてプログラムをしないのかねぇ。で、あらかたプログラムを書いた後に、

プログラムを書く時って…

自分だけで使うプログラムを書く時は適当に書き始めるのだが、僕の場合、お仕事でプログラムを書く時は最初の1行目を書き始めるまでの時間が異様に長い。今後の保守性だとか、環境の持続性だとかに縛られるので。MSさんがもうちょっと後先考えてくれれば良いんですけれど。ころころ変わりすぎて、MSのツールを投げ捨てたいんだけど…
VBAはこれまでさんざん書いてきたけれど、個人的にはかゆいところに手が届かないので悩ましいのであるが、さらにExcelやWordの文書の中に入っちゃうので、ソースの履歴管理に問題があるので、あまり使いたくないのです。ただIDEはMS-Cのころからこんな感じなので、それなりに使い慣れているせいか、悩ましい存在だったりする。(オブジェクトのメソッドやらプロパティを打ち込むのもめんどくさいので、あれだけ補完入力が効いてくれると便利なので。)
ということで、今日はこれから書くプログラムのデータ構造を決めるのに結構な時間を要し、とりあえず基礎の部分を作って1日おしまい。スロースタータなんですねぇ。
ちなみにMSのツールを捨てられないのは、よけいなインストール作業を繰り返すことになるからなのね。少なくともExcelはどのPCにもインストールされているので、これになかなか勝てないのです。

GNU R

まじめな統計計算を滅多にしないので、Excelで十分かと思っていたが、ずいぶん前から直らないバグが結構あり、場合によって_Fatal_なので、Excelでの統計計算にあきれていた。かといって、proprietaryな統計計算パッケージ(たとえばSとかS Plusとか)は非常に高価で入手不可能であるため、Excelを我慢してうまく使い続けてきたが、GNUのSとも言うべきRの日本語化が結構な勢いで進んできたので、これはしたりと思ったわけである。Rって何?と言う人もいると思うので、以下にR Projectのページに載っている説明文を載っけてみる。

言語の勉強のためにインタプリタを書く?

うーむ、最近Raccの勉強中。Rubyを勉強するためにRaccでインタプリタを書いてみようと言うことで、いろいろ遊んでいる。今のところはRaccの256本に掲載されているBASICもどきな言語を学びつつ、もっと別の文法を持つインタプリタを書いて遊んでみたいなぁ。(BNF記法実に深い…)
いずれにしてもそろそろ正規表現をまともに取り組まないとならないなぁ。

VBAでプログラム書き

ここ3年ほど保守している仕事に使っているExcel VBAのマクロなのであるが、当初の開発目標をおおむねクリアできたような気がする。やはり自分が使うツールの改良は楽しいし、自分が作ってきた種々のツールのコードをライブラリの共通化による統合が行えるとなかなか快絶な喜びだ。唯一悲しいのはVBAであると言うところか。VBAがやっぱり好きになれないと言うところとCVSでコードの管理とかできないじゃんと言うところが悲しい。
VBA周りで考えていきたいのは、_VBAからActiveScriptRubyのオブジェクトとやりとりできないものか_と言うことと、上記のマクロのclassライブラリ化かなぁ。Rubyを使えればテキストデータのパースをRubyにやらせて、Excel出力をVBAなんて事ができそうだし、後者はコードをOOP風に整理しておきたいんだよなぁと思うのだ。どうなんだろう。気が向いたら調べていこう。