クリアって cat /dev/null > dirty.rb ってことですか?

まずスライドでぎょっとしたのは、「クリア/clear」を「クリーン/clean」の意味で使っていること。これだと実はこういう意味になる。

% cat /dev/null > dirty.rb

たしかに size = 0 のコードほどクリアなコードは存在しない。実際英語では"clear"という単語は形容詞としてより動詞としての方が遥かに用いられるし、動詞として使うとこちらの意味になる。あえて和訳すると「粛正する」といったところだろうか。

美化/beautify の意味であれば、 clean か tidy の方がいい。これなら「元の木阿弥になる」ことはない。余談であるが Perl の場合は perltidy というモジュール/コマンドがあるので私はそれを愛用している。Emacs や CotEditor からも使えるようにしてあるので、blog に貼付けるような snippet でも tidy になって本当に気持ちよい。Cにはindentが昔からあるし、JavaScriptだとjsbeautifier.orgのようにオンラインで使えるものも結構ある。rubyの場合はどうだろうか?そもそも不要という意見含めて。私自身Pythonでこの手のツールの必要性を感じたことはほとんどないし。

壊れてもないものを直すべからず

しかし、本当に悲しくなったのは、スライド11ページ。

汚れていくコード
(Code gets dirty...)
✓ 直しても直しても
他の人が汚していく
(I clean codes but others make codes dirty...)
✓ 掃除しているそばから
ゴミを捨てられているよう
(Like ... I can't translate it... :<)

「直しても直しても他の人が他の人が汚していく」って、それって本当に他の人なんですか?

あなたは人のコードを汚した経験は一度もないのですか?

いや、それよりも度し難いことだけど、人のコードをきれいにしようとして、その結果壊した経験はないのですか?

こんな会話を思い出す。

弾の部下

なんか/binの下に[ってファイルがあったんですが、気色悪いので消しときました

もちろん私は彼を叱責した上で、 ln /bin/test '/bin/[' として修復したけれど、この手の code clearing はソフトウェアエンジニアを四半世紀もやっていれば何度も出くわす。で、圧倒的多数の場合、自分のコードを clean 通り越して clear にしているのは、自分自身。よりにもよって、 Encode でそれをやっちまったことすらある。

If it ain't broke, don't fix it.

「壊れてもないものを直すな」。英語版はわざと broken な言い回しをしているところも微笑ましい。コードを直す際には、必ず思い出すようにしよう。人様のコードに手を入れる際には、なおのこと。

それではどうしたらよいか?

コードを直す前にテストを書いておくことである。

本書では、第14章がカヴァーしている。

本書で好感を持てたのは、テストを奨励する一方、TDD原理主義も戒めていること。たしかに「コードを書き下ろす前にテストを書く」というのは正直やりすぎだと私も感じるし、私もそうしていない。そのコードを最初に実行するのは書いた本人であって、テストコードに「初夜権」を明け渡すのはよほどのNTRマニアだと弾言させていただく。

しかしコードを人に見せたり、ましてや直したりする場合には話は別だ。Ver. 0.0の段階ではあなた自身がユーザーであなた自身がテスターであるが、リリース後はそうではなくなる。たとえ自分が自分のコードを直す場合ですら、それは過去の自分という他者が書いたコードなのだ。

Perlコミュニティはこれに関して非常に厳しい。CPANに至ってはtestに通らなければインストールすらそこで止まる。そしてblogの1 entryのためにPerl以外の言語で「書き流した」コードにすら叱責が飛ぶ。

先生！テストがないと使いたくありません！＞＜ / “404 Blog Not Found:javascript - hanzenkaku.js で半角全角処理” htn.to/CGEoKJ

— Fuji, Goro (@__gfx__) August 13, 2012

まったくもっておっしゃる通りなのでそのようにした。この年になっても干支一回り違う若者にこういってもらえる私は果報者である。JavaScriptでどうやるのかというのは今まで結構な難題ゆえついつい後回しにしてきたのだが、今ではnode.jsもMochaもある。外堀は埋まっているのだ。

しかしMochaを使い始めた最大の理由が、TAPもサポートしていたこと。思うに他の言語におけるTDDがかけ声ばかり大きな理由の一つは、テストコードにまでクリーンを求めていることではなかろうか。それではテストを書くのに必要な気力が増えてしまう。テストコードはウェスである。毎日洗濯するものではないし、本体コードと一緒に洗濯機に放り込むべきものでもない。しかし仕事場をクリーンに保つには欠かせない。

バグを憎んで人を憎まず

スライドに話を戻す。ぎょっとして悲しくなって、しかし「あれ」さえあれば、私は気を取り直すことが出来た。「リーダブルコード」にあって同スライドにないあれさえあれば。

コード、である。

同スライドには、一片のコードもない。コードへのリンクさえ、本書の書影を除けば見当たらない。これでは、自己啓発セミナーと何が違うのか私にはわからない。

たしかに同発表の主題はコードそのものではなくコーディングである以上、コードそのものは内容的には必須ではない。しかし心理的には、その違いはあまりに大きい。なぜか?

コードなしには、それが本当にきれいにするに値するのかわからないからだ。

コードなしでは、人を憎んで罪を憎まずになってしまうからだ。

「おまえのコードは汚い」と言われて喜ぶ人はいない。外交で言えば「尖閣諸島買います」以上の悪手である。

あくまで「このコードはこうすればもっときれいになります」でないと、自分自身を含め誰も受け入れない。人間関係をクリアにしたいのであればとにかく、友好関係を続けたいと欲するのであれば、「汚す人」を対象としてはならない。対象は、あくまで「汚れたコード」でなくてはならない。

だから、私はスライドにはコードは書かずにいられない。書くだけに留まらず、lleval以降は実際その場で動かせるようにしている。たとえそれが「外国語」で「アウェイ」でも、具体的なコードがあれば具体的に批判ができるし、そして何よりも相手に具体的な反論、反証する余地が与えられるからだ。

それが、バグを憎んで人を憎まぬ、私が知っているたった一つのやり方だから。

本書には、それがふんだんにある。しかも言語をまたがって。だから本書自体も「本当にリーダブルなのか?」という反証可能性を、サンプルの言語がネイティブでないユーザーに対しても与えている。優れた書というのは、非のうちどころがない書のことではない。読者自身が非を直せる書のことである。

おわりに - コードは使ってなんぼ

コードは書かれる機会より読まれる機会の方がずっと多い。おっしゃるとおり。

しかし読まれる機会よりはるかに、使われる機会は多いのだ。

書く ＜＜ 読む ＜＜＜＜ 使う

健全なコードであれば、頻度はこうなっているはずだ。

読みやすくのために使えなくしては、size = 0 の「クリアな」コードにすら劣る。

Am I making myself clear?

Dan the Dirty Old Coder