ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

ルール20計算をやっておけ

　本書は、あまり数学的な本じゃない。確かに、いくつかのルールには数字が出てくるが（ルール4「一般化には3つの例が必要」やルール11「2倍良くなるか？」等）、ルールは、方程式っていうより概念だ。

　コンピューターのプログラミングに、現状必要な程度以上に数学が出てこないのは、ある意味驚きではある。結局のところコンピューターってのは、単なる数字処理機械なのだ。処理のために、全ては数字に換算される。言葉は数字で表された文字の並び、ビットマップは数字で表された色で表現されるピクセル群、音楽は一連の数字で表された波形の組み合わせだ。そういう数字のうちどれかが漏れ出してきて──プログラマーであればどこかの時点で、数式を解いてるんじゃないか、なんて思うかもしれない。でも、あまりそういうことは起こらない。

　プログラマーが下す判断のほとんどは曖昧だ。例えば、長いコメントの追加で明確さが増すとして、ロジックのフローをややこしくするほどの価値が、増した分の明確さにあるかどうかの判断。関数の名前をgetPriorityにするかcalculatePriorityにするかの選択†1。何かのシステムを新バージョンに切り替える適切なタイミングの見極め。

†1　Sucker Punchにはこのための規則があるのを知っても、きみは驚かないだろう。「get」は計算をしない（あるいはほとんどしない）ことを意味し、「calculate」とか他の似たような名前は、値を生成するために作業が要ることを意味する。こういう規則は、関数が何をするものかを理解するための、いいきっかけになる。

　ほとんどの判断に留まらず、あらゆる判断は曖昧である、という考え方に陥ってしまいやすい。でも単純な計算に帰結する判断もあり、そういう判断が出てきたら計算すれば済む判断として認識しなきゃいけない。認識せずに、単純な計算をやらないで突き進んだら、後で痛い目を見て思い知らされる事態がきみを待ってるかもしれない。自分がなぞっていたアプローチは絶対にうまくいかないものだったんだ、先に計算しておくだけで時間を相当節約できたはずなのに……と気づくかもしれない。そうなると悲しいので、先に計算をやっといた方がいい ...