大昔、微生物と感染症が発見される前のこと、ヨーロッパの外科医は、血染めのガウンを着て外科手術をした。このガウンはずっと同じ一着を使いつづけ、けっして洗わない。
血のついていない真っ白なガウンを医者が着ていると、「まだたいした外科手術をやったことがない新米」という意味になる。たくさんの血を吸って赤黒くごわごわになったガウンは、「数々の大きな外科手術を経験してきたベテラン」という意味になる。ガウンを染める血は、医者の経験の証だった。
微生物と感染症が発見されてからは、血染めのガウンはなくなった。そのかわり、高温殺菌オレンジジュースが現れた。
食物経由の感染症を恐れるあまり、殺菌していない食物を徹底して避けるようになり、生の果物まで避けて高温殺菌オレンジジュースを飲む、という次第だ。オレンジジュースを加熱すれば、ビタミンCは失われる。日本の有名人では森鴎外がこれをやった。
ビタミンが発見されると、メガビタミンの登場である。メガビタミンというのは、「必要量以上にビタミンを摂取すると寿命が延びる」という妄想だ。
人間は指標に振り回される。経験→微生物→ビタミン、というわけだ。新しく現れた指標に振り回される人間は滑稽だが、昔ながらの知恵、いわゆる「ベスト・プラクティス」は血染めのガウンかもしれない。
プログラミングの世界にも、血染めのガウンと思しきものがある。たとえば、「ルーチンの行数を短く（数十行以内に）しておけ」がそれだ。
Steve McConnell『Code Complete 第2版』（日経BPソフトプレス）上巻213～214ページから引用する：
・BasiliとPerriconeによる調査では、ルーチンのサイズがエラーと反比例することがわかった。ルーチンのサイズが増えるにつれ（最大で200行のコード）、コード1行あたりのエラーの数は減っていく（Basili and Perricone 1984）。
・別の調査では、ルーチンのサイズにエラーとの因果関係はないが、構造的な複雑さやデータの量がエラーに関係しているという結果が出ている（Shen et al. 1985）。
・1986年の調査では、小さいルーチン（コードが32行以下）とコストまたはエラーの発生率の減少とに相関関係はないことがわかった（Card, Church and Agresti 1986; Card and Glass 1990）。このことは、ルーチンが大きくなるほど（コードが65行以上）、コード1行あたりの開発コストが下がることを示している。
・450個のルーチンで実験を行った調査では、小さなルーチン（コメントを含め、ステートメントの数が143行未満）は、大きなルーチンよりもコード1行あたりのエラー率が23%高いものの、修正コストは逆に2.4倍も少ないことがわかった（Selby and Basili 1991）。
・別の調査では、コードの修正が最も発生しにくいのは、平均して100～150行のルーチンであることがわかった（Lind and Vairavan 1989）。
・IBMの調査によると、最もエラーが発生しやすいルーチンは、500行以上のものであることがわかった。500行を超えると、エラーの発生率はルーチンのサイズに比例する傾向にある（Jones 1986a）。
200行以内のルーチンを分割すべき理由はない。「ルーチンの行数を短く（数十行以内に）しておけ」というルールは、長いルーチンがいくつかの短いルーチン（どれも1箇所から呼ばれるだけの）に分割される、という結果を生む。これはコードの長さ（＝目につきやすい指標）をコールスタックの深さ（＝目につきにくい複雑さ）に変換して、バグを増やすだけだ。
かといって、長いルーチンがよい兆しなわけもない。長いルーチンがたくさんあるのは、悪い設計やコードの重複の兆しであり、「長いルーチンは不吉」となら確実にいえる。指標としては有効なのだ。
「ルーチンの行数を短く（数十行以内に）しておけ」というルールの問題は、「指標をいじっているだけで、実態は改善どころか悪化する」という点にある。まさに血染めのガウンだ。
どんな分野であれ人間が努力するところには、血染めのガウンやメガビタミンがある。ただ努力するだけでなく成果を出したいのなら、指標に振り回されやすい人間の性質を知ろうと努め、血染めのガウンやメガビタミンと思しきものを日々探すべきだ。このような態度こそ知恵である。
私はいま、Pete Goodliffe『Code Craft』（毎日コミュニケーションズ）を読んでいる。
知識はなるほど詰まっているが、知恵のほうは『Code Complete』に及ばない。ソフトウェア工学の知見があまり紹介されていないし、俗耳に入りやすい迷信への反駁も少ない。正直なところ、著者が筋金入りのプログラマかどうかも疑っている。
本書を読むかどうか迷っているかたには、367ページをご覧になることをお勧めする。私の知るかぎりでは、「hack」には「華麗なやっつけ仕事」というニュアンスがある。膨大な作業量を伴う仕事は、どんなに華麗なものでも「hack」とはいえない。基礎工事のような地味な仕事はなおさらだ。このため、ちっとも華麗でない手抜きしただけの仕事を正当化するために「hack」という言葉が使われることが多く、自称としての「hack」は危険な兆候だと感じている。しかし著者の知る「hack」はそうではないようだ。ああいう綺麗事の「hack」が許せるなら、本書を読んでもいいかもしれない。