書籍コード

最近はあまり本番コードは書きませんが、それでもかなり多くの時間をコードの執筆に費やしています。このコードは、書籍の中でアイデアを説明するためのもので、独自の形式がとられています。書籍のコードは本当の実コードとは少し異なります。執筆時には考慮すべき要素が異なります。

1つの問題は、言語の選択です。読者の多くが理解してついてこられる言語でコードを書く必要があります。プラットフォームに依存しないアイデアについて書こうとしていますが、コードは正確である必要があります。そのため、多くの人が理解してついてこられる、広く使われている言語を選択する必要があります。

初期のころは、2大オブジェクト指向言語はSmalltalkとC++でした。どちらも欠点がありました。SmalltalkはSmalltalkを使わない人にとってはあまりにも風変わりすぎ、C++はうまく使いこなすにはあまりにも難解でした。自分にとって救世主となったのはJavaです。C/C++の背景を持つ人なら誰でも読むことができました。ほとんどのSmalltalkユーザーでさえ、鼻をつまんで私のコードを理解することができました。それがリファクタリングの書籍がJavaで書かれた理由です。

その後、.NETが登場しました。ここでは、C#がほとんどJavaと同じであったため、私は2つをほぼ同じように使用できました。両方を用いることで、私が書いていたアイデアがどちらの場合でも有用であることを強調したいと考えていました。

最近は、特にDomainSpecificLanguagesについて書く場合には、状況がより困難になっています。JavaとC#は乖離しつつあり、私が説明したいもののいくつかは、どちらの言語にもない機能を必要とします。個人的なプログラミングの多くをDSLに非常に適したRubyで行っているため、このような状況では第一候補としてRubyを使用します。ただし、他の言語も貢献しています。DSLのさまざまな言語機能を説明するためには、書籍が言語の細切れ情報のごった煮にならないようにバランスを取る必要があります。

書籍のコードに関してもう1つ注意すべき点は、一般的な読者にとってではなくても、私が使用している言語に精通している人にとってさえ不明瞭な言語機能を使用しないことです。良い例として、Rubyを使用して例を書く場合、自分のRubyコードでは多用しているにもかかわらず、コレクションパイプラインの使用を避けました。これは、中括弧を使用する背景を持つプログラマーは、このような式を理解するのが難しいためです。そのため、そうした読者に届くように、流暢なRubyをあえて犠牲にしました。

DSL書籍では再びこれがより困難になります。内部DSLは、可読性を高めるためにネイティブ構文の悪用を伴う傾向があります。このような悪用の多くは、言語の風変わりな部分に関連しています。ここではも、可読性のあるDSLコードを示すことと、風変わりな部分にどっぷり浸ることをバランスさせる必要があります。