日々の破片

_ COMの再入問題

Excelが終らない件とは関係ない話。

STAでメッセージポンプを回すCOMのサーバーを作ったとする。

HRESULT foo() 
{
   m_pOuterProcess->bar(); // 外部プロセスサーバーへ問い合わせ
   return S_OK;
}

この場合、外部プロセスサーバーの呼出し中にメッセージポンプが回る。ここでは他のメッセージを受け入れる。なぜならば、コールバック（イベントの呼び出し）が行われる可能性があるから。

しかし、もし、fooというこのメソッドの呼び出しがシリアライズされなければならないとしたら、話がいきなり厄介になる。

同期させるわけだからと、

HRESULT foo() 
{
  m_criticalSection.lock();
  m_pOuterProcess->bar(); // 外部プロセスサーバーへ問い合わせ
  m_criticalSection.unlock();
  return S_OK;
}

とやっても、なんの役にも立たない。というのは、STAなんだから、外部からの呼び出しは、このスレッドに対して行われるからだ。自スレッドの同期オブジェクトのロックは待ち状態になるわけにはいかないから単純にスルーされてしまう（ロックカウントは上がるはずだけど）。

つまり、再入されてしまう。

ここで、fooがインスタンス変数をいじるととてもまずいことになる。で、それに対応できない場合は、再入不可能だから気をつけて下さい、とクライアント側が同時に呼び出さないことを求めることになる。

これを回避するには、IMessageFilterインターフェイスを実装して、メッセージポンプに介入する必要がある。が、今度はデッドロックの可能性が出てくる。ASRですな。

_ ものを作るってこと

まあ、とある事情があって、待ち状態になる機会が結構な頻度である。たまたま、数10冊ほど本が置いてあるから、最初のうちは矢野徹が翻訳（とは思えないから下訳の日本語化ということだろうが）した子供用モンテクリスト伯とか読んでたんだが、あるときから見えなくなったもんで、何気なく町工場がどうしたってのを読み始めた。

ら、こいつが結構、ツボにはまった。

たとえばこんなエピソード。

プロペラの依頼が来たんだが、すごく固い上に薄く削る必要があったり大変なんで、忘れちゃったけどなんかの合金で固めて旋盤かける方法を考え付いて（この合金がミソなんだが忘れた: 3/22追記 Uアロイという合金。なお、このエピソードは198898の本の中で、今から20年ほど前のこと、とされている。あおしまさんの指摘が正しいと思う。センジュはメーカー名だから）削ってたら、別の町工場の親父が見てる(町工場ってのは表から中が見えるらしい)。で、近づいてきて削られたクズをペロリとなめて、鉛が少ねぇな、だか、変な半田だな、とか（3/22追記 実際には噛んでみて「錫が少ねぇ」。錫は噛むと鳴るので熟練すると噛んだだけでわかるらしい。またその親父は勝手に覗いていたんではなく、まだ珍しかったNCマシンの見学のために来ていた）。

そんな芸当をするのは、年期が入った職人だけだから、そりゃまじめに相手をせざるを得ない。で、いや、こりゃ半田じゃなくて、プロペラ削るんでいろいろ探して見つけたなんちゃらって合金で、こいつを使うとこれこれって理由で具合がいいんだ。どう具合がいいかっていうと、最後の仕上げの時になにかをするとぱかっと割れてプロペラだけが取り出せる、とか説明すると、親父、そりゃいい話を聞かせてもらった、じゃ、おいらのやつも教えてやる。

新幹線の下につけるステンレスの箱を作れと依頼が来たんだが、話を聞くと箱じゃねぇ。穴がそこら中にあいてるから、早い話が網なんだな、これが。

で、穴をあけたらうまく折曲がらない。先に折ると穴がうまくあかねぇ。鉄板に付けたらうまく曲がるがうまく取れない。で、おめぇさんならどうする？

うーん、考えないとわからんな。

そうよ。で、おいらも考えながら歩いていたら、表具屋の店先ではたと気付いた。で、和紙を買ってきてだな、表具屋に張ってもらったのよ。これで自由に加工できるようになったってわけだ。ありゃ、丈夫だからな。で、最後は水にどぼんだ。

なるほど、そういや、障子の張り替えは昔は川でやったもんだったな。

そのとおり。お前さんのその合金と同じだよ。

Amazonのブックレビューを読むと眠たいことが書いてあるが、デペンデンシインジェクションとかハリウッドメソッドなんてのは、まさにこういうことだ。加工しにくい素材を扱う場合は、外し易い補助材を使うっていうデザインパターンだな（それだけじゃなくて素材の発見っていうストーリーもあるな）。

_ 今思ったこと

jni.hはきれいだ。
たとえば、jvalueという共用体が定義されているが、jdoubleはdだし、jintはiだ。
こういう名前って、センスが無いやつにやらせると平気でdoubleValueだのintValueだの馬鹿気た名前をつける。もっとも全体の長さに合わせるべきだから、java.lang.IntegerのintValueとかはしょうがないとは思うが。
というわけで、たまに、次のようなゴミのようなプログラムを見ることがある。

if (hoge) {
  long currentDepositAmount = accountInfo.getDepositAmount();
  newAccoutInfo.setDepositAmount(currentDepositAmount + ビジネスルール);
}

バカですか？
たかだか数行のスコープで、しかも、ゲッタとセッタのpublicメソッドから、何をつかんでいるかは明々白々にもかかわらず、long currentDepositAmountなんて馬のイバリみたいな名前をつけるなんて、なんの意味もありませんな。
もし、こう書かなければ理解できないとしたら、それを書いたヤツはpublicインターフェイスの名称がどういう意味を持つかわかってないと思いこんでいるのか、さもなきゃ、ソースを読むやつをバカにしているかのどちらかだ。
まともな人間なら、現在のアカウント情報に保持されている供託金を新規アカウントの供託金にビジネスルールを適用して突っ込んでるとわかる。もしわからないと仮定するのであれば、accountInfoだのgetDepositAmountだのって名称そのものがそもそも無意味だってことだ。
当然、こんな場合は

if (hoge) {
  long l = accountInfo.getDepositAmount();
  newAccoutInfo.setDepositAmount(l + ビジネスルール);
}

のほうが遙かに良い。こんな短いスコープの変数に時間を0.05秒でも余分に使う閑があったら、目でも休ませてなってことだ。
つまりだ、これは「メリハリ」をつけるってことだ。
子供の作文ってのがある。 「朝起きて、歯を磨いて、顔を洗って、ごはんを食べて、牛乳を飲んで、頭をかいて、靴下のにおいをかいで、猫を撫でて、ヘリコプターに乗って、へそでチャをわかして、学校に来て、先生に挨拶をして……」
すべてを同じ調子でやってたら、バグが入ってても見つけにくいじゃないか。
ここぞってとこは強調し、どうでも良いところは見えなくする。
それがメリハリをつけるってことだ。
ローカル変数なんてのは、そのブロック内だけでしか意味を持たないどうでも良いものなんだから、そんなものに有意味な名前をつけてはいけない。
もちろん、例外はあって、

for (int outer = 0; outer < dendekodennsuke.getFukusuke(); outer++) {
  for (int inner = 0; inner < denndekodensuke.denkihaTaisetuni(); inner++) {
 ....
 innerループがある特定の数でかつouterループの何番目かの時点では非常に特殊なことをする
 ...
  }
}

ってような場合に、int iとint jってのは「非常に特殊なこと」をする条件がわかりにくくなる。こんな場合には、コンテキストが明白になる名前をつけるべきだ。
しかし、「こんな場合には……べきだ」ってのはルールとするのは曖昧だ。
曖昧なことはルール化できない。であれば、原則論を主としなきゃならないのは当然の帰結となる。
したがって、ローカル変数は、1文字か2文字にして、ブロック毎に作れ。ブロックはできるだけ5行長くても10行。それを越えたらルールを単位としたメソッドとして別立てにし、メソッドコメントとしてルールを記述せよ、ってことになる。ちなみにメソッドレベルのローカル変数はもうちょっと長くしたほうが良い。この例だとdepositAmtとか。まあ、currentDpositAmountでもいいけど。でもdepositは長すぎるから3文字短縮語辞書を作っておいたほうがいいだろうな。curDepAmtとかだな。つまり、3文字略語の複合がメソッドレベルのローカル変数にはちょうどリズムが良い。
まあ、ローカル変数名が5文字を越えてたら、バグの前兆ってことだ。

_ 1文字変数名の規則

i, j これは古いFortlan（綴り忘れたから違うような）から持ち込まれた由緒正しい変数名の規約で、整数に使用する。その後、iterationの意味も含まれるようになったため、for文のインデックス値に利用する。

c これは一般には文字に使用するが、別解として、counterの略でint c = 0; ... c++;なものに(iterationの場合は、i)に利用する。

ただし、C/C++のようにポインタのサイズが重要になる場合には、

cb (counter of bytes), ci (counter of ints), cs (counter of shorts)などとする。このへんは由緒正しいハンガリアン由来。

n ニューメリック一般だが、iがiterationに取られるため、intを示す。

o, d, f, l わからないやつは言語仕様を読め。というくらい当然のように利用する。

p pで始まるすべてだが、oと異なり途中で参照が変更される可能性を持つオブジェクトを示す場合に使用する。

e 例外

r rで始まるすべてだが、特にレコードの概念を示す場合に利用する。

f これはboolean。bはbyteに利用する。この場合のfはflag valueの意味。これも由緒正しいハンガリアン由来。ただしFileの概念を持つ場合にはそちらに優先的に与え、同一ブロック内で真偽値が必要になる場合には、例外として意味的な名称(continueToReadなど）を真偽値に与える。というか、制御に利用する変数名は実際には長い名前にしたほうが良い。そのほうが妙な修正による誤った流用を回避できる。ただし、つい流用したくなるってのはブロックがでか過ぎる証拠。

x, y, z ……i, j が不足した場合に利用しても良いが、そんなにfor文を重ねてはいけない。むしろ、数値計算の過程で利用する。

np, lp, これは使うべきではない。あまりにも歴史的。

これ以上ローカル変数が必要になるとしたら、書き方がおかしい。それはブロックやメソッドを分割しなければならない。

追記：まあ、まじめに考えればすぐにわかることだが、オブジェクトはアイデンティティによって区別されるんであって、変数名で区別されるわけじゃない。そこがわからないと馬子にも衣装とばかりに変数名に凝ってしまうんだろう。だが、値が入ってるならともかく（というか、値自体がテンポラリな存在なわけで）しょせん参照に過ぎないわけで、まったくオブジェクトそのものとは関係は無いわけだ。したがって、読みやすさと記述力を優先するのは当然。

_ >900

よっしゃわかった。じゃあ、longの先頭2文字で

long lO = 10;

とか（大文字のOは勘弁だな）。

#実際には、longを取る値であれば、入る内容の略語を使ってcntとかamtとかqtyとかすることが個人的には多い気がする。あと、ニュートラルな場合（intでもlongでもどっちでもいいけど大きいことはいいことだでlongとなっているような場合）にはnが多いな。

ちなみに、jni.hでは、jobjectがlで、jlongはj （iの次だからか?）となっている。

っていうか、ローカル変数まで長い名前を付けたがるのは、メインフレーム方面から流れてきた連中なんじゃなかろうか。だから、Sunのコーディング規約（多少のブレはあるが、Unix流儀）に文句をつけるんじゃなかろうかね。

古いCOBOLにはローカル変数っていう概念がないから、なんでもかんでもグローバルな変数と同一の流儀で変数名をつけようとしでかすんじゃなかろうか。

ちゃんとスコープを理解してるのかなぁ。

略語の問題は、人によってln, len, lgth, lg, とかいろいろあるから困ると言われているが、スコープが限定された変数はなんでも良いってのが最初にあるわけだから、どれでも構わない。つまり、困らない。

あたりまえだが、インターフェイス名やそのメソッド名にCalAMt#ccとかするのはだめでしょう。やっぱりCalendarAmateur#CCompileとか付けなければわからないし。