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

ルールに反対する方法

　読者が21個のルールをすんなり読み進めていくようなことがありませんように、ってのがぼくの願いだったりする。

　各ルールと、その例としてぼくが用いてる話を、「うんそうだ、これは分かる、こういう例はよく知ってる、自分はそんな考えを前に抱いたことがあって、自分の場合別の言葉を使って説明したってだけでね」なんて調子で、きみが礼儀正しくうなずきながら読み進めていたりしたら。んー、そいつは失敗だ。

　読者には、思索をめぐらせる対象になりうるような題材を与えたい。新しい知見の1つや2つも得られれば、理想的だ。ぼくの方からは、読者が抱くぼんやりした印象に名前を付けてやれそうだし、読者がはっきりとは特定できていないものについて明快な例を提示できそうでもある。全く新しい、考慮に値する材料を、読者に与えることだってできるんじゃないか。

　でも、同意しない考え方に読者が出くわすことだって、一度や二度はありそうだ。何かに関して著者のぼくが完全に間違っていて、ルールの中にもアドバイスとしてはろくでもないやつが混じってる、そんな風に読者が思ったりするかもしれない。

　結構なことじゃないか！ 読者にとって、自身が強く反対するルールが見つかるなら、そいつはむしろ好機だ。そういうルールを直ちに脊髄反射的に拒絶してしまうことこそ、間違いというものだろう。

　疑義が呈されるルールが、まるっきり間違いってわけじゃないことは、ぼくが保証する。でもそのルールは、ぼくらにとって正しかったとしても、同時にきみにとっては誤りであるかもしれない。何故そうなってるか理解すれば、読者が自身のプログラミング哲学を理解するとともにそれを強化することにつながるはずだ。それはすなわち、Sucker Punchと、読者自身のチームとの間にある、差異を理解することに等しい。何故ならそういう差異こそが、 ...