日々の破片

_ 続変数名

というわけで、ローカル変数名のデフォルトを無意味1文字変数とすると、次のように論が進められる。

前提：ローカル変数は1文字か2文字で付ける。(実際は、もっとゆるいのだ。別にBook bkでもBook bookでも構わない。この場合、Book bokはありえないとは思うけど、それでも構わない）

例外：特に着目すべき変数についてはフルスペルやそれに準じた変数名をつける。たとえば、

Book myGrandFathersFavoriteBook

この方法論は、次の方法論より、有効だ。

前提：ローカル変数であってもフルスペルな変数名を付ける.

Book myGrandFathersFavoriteBook

Book myGrandMothersFavoriteBook

Book myFatersFavoriteBook

Book myMothersFavoriteBook

Book myBrothersFavoriteBook

Book mySistersFavoriteBook

Book mySonsFavoriteBook

(ふむ、さらに悪いことにコピペ地獄に陥ってるな)

例外：for文のiくらいは勘弁してやる。

なぜ有効かといえば、例外的な記述は違和感を持つからだ。そのためそれが注目すべきものだということが明らかになる。

ところが、後者の場合、せっかくの例外的な状況が、まったく有効に活用できない。

それは

極上の料理にハチミツをぶちまけるかのごとく甘い思想

――範馬勇次郎

であろう。

_ 参照

これはOASISのXML Common Biometric Format TC Public Documentsだったりするのだが、ここからCommon Biometric Formatを見ると、簡単に

biometricObject.biometricHeader.format.formatType.BindedPrimaryAccountNumberっていうようなオブジェクトが集約したオブジェクトが集約した……オブジェクトの属性名とかが出てくるわけだ。

で、BindedPrimaryAccountNumberっていうのが正式な属性名になるんだが、もし変数名としてaccountNumberってのをテンポラリに使おうとしたら（それでも死ぬほど長いが）、それは既に略してるんだよね。

で、まあ、手元にメソッドの引数としてbiometricObjectのインスタンスが渡されたとする。で、いちいち

biometricObject.getBiometricHeader().getFormat()....

なんて書くのは何がなんでもくだらないから、部分で切り分けることになる。

BiometricHeader h = biometricObject.getBiometricHeader();

で、ここで、hと書かずにbiometricHeaderと書くと

BiometricHeader biometricHeader = biometricObject.getBiometricHeader();

だ。

こんな行がずらずら並んだ、真っ黒なソースから問題点を探すのはばかげている。

というわけで、

BiometricHeader header = biometricObject.getBiometricHeader();

としてみたとする。

で

header.getFormat().getFormatType()....

と書いたほうが

h.getFormat().getFormatType()....

と書くより、「読みやすい」とか「理解が促進される」とか言い出す人がいたら、やはり何か変ですな。

プログラム書いたこともなければ、読んだこともないんじゃなかろうか？

すると、恣意的なルールを持ち出したくなったりするかも。

ゲッタが4個以上になる場合は〜とするが、2個ならば〜とか。

だが、ルールは少ないほうが覚え易いし、実効性を持つ。そうじゃなければ破られるだけだ。破りたくなるようなルールは間違っている。

ショウカの法三章ってやつだ。

というわけで、ブロック内での変数（だいたいオブジェクト指向言語で記述する以上、変数の役割はキャッシュか計算の中間結果の保持用だ）の名前なんて短くても問題なし。

#まあ、可能性としては、乏しい語彙の世界でしかプログラムを記述したことが無い人間がルールだとか言ってるんだろう。としか考えられん。

というわけで、豊富な語彙の世界でプログラムを記述したり読んだりしているおいらが言っておこう。

「変数名は短ければ短いほど良い。」

#追記：当然だが、スキーマ上の要素名が長いのはまったく問題ない。こっちを省略させたり短くしては本末転倒だ。

_ 簡潔な記述のためのキャッシュ

ここで言うキャッシュっていうのは、たとえば最適化とかを意識して行うことではなく、単に短くための道具のことだ。
a.getB().getC().getD().getE();
とある場合に、
b.getB().getC().getD().setE(a.getB().getC().getD().getE());
と書くかわりに、
b_d.setE(a_d.getE());
と書いてある方が、単純に読みやすい。それは、余白が多いからだというのはいい?
で、この時に、aがソース、bがデスティネーション（クラスは同じ）という場合に、
dst_d.setE(src_d.getE());
と書くとする。
で、ここで、
desination_d.setE(source_d.getE());
のほうが、本当に、dst_d.setE(src_d.getE());
より望ましいですか？ （と、具体的な読み手が想像されると急に丁寧語になってみたり）
で、実際には、dとしているがこれが、AccountOfTheCustomerっていう要素名だと
dst_act.setE(src_act.getE());
というよりキャメルケースで、
dstAct.setE(srcAct.getE());
より、
destinationAccount.setE(sourceAccount.getE());
のほうが良い？
しかも、実際には、ここでAccountと略しているが、同じXMLの兄弟要素に、AccountOfThePublisherとかAccountOfTheShoppersとかが並列しているとする。
その場合、Accountという省略は、「わかりにくい」。なぜならば、どのAccountかが略されているからだ。
すると明晰さを求めるためには、
destinationAccountOfTheCustomer.setE(sourceAccountOfTheCustomer.getE());
で、こうなってしまえば、最初に行った「 ここで言うキャッシュっていうのは、たとえば最適化とかを意識して行うことではなく、単に短くための道具のことだ。」が無効化されてしまう。
というところで、落としどころとして、まあ、兄弟要素には目をつむって
destinationAccount.setE(sourceAccount.getE());
としたとする。
だったら、そんな「落としどころ」はやめてしまって、
dstAct.setE(srcAct.getE());
のほうが良いのではないか？
ってことなんだけど。
#あと、上じゃ忘れてるが、前提はスコープの狭さにあります。 #わざとクネクネカーブの道を住宅地に作り時速20Km制限を守らせようとするのに近いのかも知れない。
#変数名は短くて良いとすれば、よろこんでhとかsとかを使いまくるだろうと前提しているわけだ。
#反省略/フルスペル派は、やっぱり放っておけば、そうなって荒れると危惧してるだろうと想像できるから、この前提は良いと思う。
で、実際に書けば、よほどセンスが無ければともかく、iとかsとかnとかで100行もあるブロック作れば、いったいおれが使っているこのsはなんだったか? となるんじゃなかろうか。
つまり、短い変数名は狭いスコープを強制し、かつ、「放っておけば省略した短い変数名を使うんじゃ無かろうか」の危惧のもとになる人間精神の方向に沿ったルールだと思う。変数名をどうつけるかより、スコープを短くとり、実行している処理を局所分割してあるほうが、後からソースを読んだ場合の読みやすさは上だと考えるというか、実際に読みやすい。
しかし、ひねくれた人間はいるから、短い名前をつけろ、と言っているのに、昨日の最初の引用のような、どう考えてもメソッド名をコピペしたような変数を作って、しかもたった5行くらいのスコープで使われるとたまらんなぁ、ということだったり。 などとやっている間にも、1000行くらいのメソッドに変数名hだのを使ったソースが量産されているという罠。
にも、かかわらず、1000行も真っ黒なコードで埋められるよりは、スカスカしているほうが読みやすいから、短い名前のほうがやっぱり好きだ、となるんだけど。 （っていうか、1000行もあったら、変数への代入が出てきた時点でメソッド呼び出しに変更していくしかないだろうな）
#しかし、世の中にはインテリセンスとかメソッド補完といったおそろしいツールを装備した開発環境があるから、素直に記述させると、
b.getB().getC().getD().setE(a.getB().getC().getD().getE());
が編集画面の全体を覆ってしまうという罠。
それと同時に、兄弟Accountがいくつあろうが、順番に処理するのであれば、

AccountType accounts[] = getAccounts(a);
for (int i = 0; i < nrOfAccount; i++) { // nrOfは良く使うな
    accounts[i] = null;
}

の都合2カ所しか使われない変数のために、accountsなんて打ち込むのはあまり意味がないと思うのは事実。
そのいっぽうで、メリハリってことに関しては、

AccountType as[] = getAccounts(a);
for (int i = 0; i < nrOfAccount; i++) { // nrOfは良く使うな
    as[i] = null;
    if (i == PUBLISHER_ACCOUNT_INDEX) {
      publisherAccount = as[i];
      ....(publisherAccount);
      publisherAccount.xxxx(ssss);
      .... = publisherAccount.getxxx();
    }
}

のほうが良いと思うのだが、その瞬間に、この内容は、

AccountType as[] = getAccounts(a);
for (int i = 0; i < nrOfAccount; i++) { // nrOfは良く使うな
    as[i] = null;
    if (i == PUBLISHER_ACCOUNT_INDEX) {
      setupPublisherAccount(as[i]);
    }
}

というように、メソッド名によって吸収されてしまうのであった。 で、追加があって、setupPublisherAccountというか、最初の要素名にあわせればsetupAccountOfThePublisher()という名前になるわけだが、このメソッドは名前からいっても特定要素の関心空間だってのは自明だから

private void setupAccountOfThePublisher(AccountType a) {
      ....(a);
      a.xxxx(ssss);
      .... = a.getxxx();
}

となってしまう。これはイヤなんだろうなぁ、と想像できるが、ここで引数がAccountOfThePublisher以外の意味になることはありえないんだから、暗黙のselfが欲しいくらいでaと書くのさえばかばかしく感じるので、(AccountType account) { とはやはり書かない。
というか、自動生成じゃなければ、こんなメソッドはAccountTypeクラスに入れたいところだがよく考えてみればそれはおかしい(AccountOfThePublisherという特定の要素に関連）のでインスタンスの特異メソッドであるべきなんだろうがそんなものは無いから（たった1つの初期化メソッドのために無理矢理AccountTypeへのデコレータを作ってそこに入れるとはしない）、ここではコントローラに持たせてしまっているから仮引数なんていうものが必要になるのであった。
でも、copyAccount(AccountType source, AccountType destination);
くらいだとsrc,dstとする必要もないようには思うので（しても全然良い）、そのメソッドの処理範囲によって仮引数名の長さが決まる（が、こんなのは恣意的なルールだから、ローカル変数と異なり、メソッドレベルの命名規則の適用ということで、aは原則だめですなぁ、となる）。

_ ふむ。

適切な名前が付けられない、キャッシュ的なlocal変数を作るハメになったら、どこか、何か理解や設計の間違いがある。

実は同じことを言ってるように思える。

本来は、local変数というのは、パラメータやループのインデックスくらいしか出てこないものなのだ。これは同じ認識だと思う。

その出てこないほうがいいし、出ないようにもできるんだが、そこまでやり過ぎるのはかえって無駄であろうと判断した場合（たとえば、上のsetupAccountOfThePublisherメソッドをこの要素限定にするためにAccountOfThePublisherTypeというクラスを作るというようなこと）に、そうは言っても適切な代名詞を使うべし（って、srcはまさに3文字略語だと思うんだけど。だったらhdrでもいいじゃん）と考えるか、そんなの使い捨てなんだから短きゃ短いほど良し、と考えるかって「ここまで認識が異なる」ってほど重要な点かな（もちろん、重要なんだけど、後述）。

本質的にはどうも一致しているんだが、枝葉の部分で異なるってのがそんなに重要かと聞かれれば、「表現」ってのはまさにそれだ。

同一の内容を書いた文書であっても、ですます調、である調、2ch調、べらんめえ調で、全然、印象が異なる。当然だ。

で、おそらく、一般論としては「文語」であるべきだということなのであろう。ここが認識の相違で、僕は「口語」のほうが読みやすいと感じているのだ。厳密度は微妙に（スカスカすることは逆にノイジーである）口語のほうが落ちるのだが、そのかわりに文語には無い、リズムが生まれると感じているからだ。つまり、喋るように記述せよ、ということだ。

困ったことに、こと本質ではなくて表現にかかわる意見の相違ってのいうのは意見の一致を見ることは難しい。というか、あまり意味がない。だから仮に一緒に仕事する機会があったら、じゃんけんか多数決で「コーディング規約」を作って遵守するってことになるだろう。その時は、グーを出してください。僕はパーを出します。