英語ライクなコードを書くことで可読性と表現性を達成しようとするのは、今日の業界において一つのトレンドとなっている。これは特にDSLとBDDコミュニ ティにおいて当てはまる事だが、Java、C#、かもしくはRubyで作業しているたくさんのデベロッパ達もまたコードを出来る限り英語に近く見せようと試みている。
Michael Feathers氏は自身の記事"The Narrative Urge(source)"において”コードは英語に近づくにつれ向上する”というアイディアに挑んでいる。Martin Fowler氏とNeal Ford氏が行ったDSLに関するプレゼンテーション(参考記事・英語)において取り上げられていたように、表現性と可読性は保持性の向上とまたプログラマとビジネスの隙間を埋めるのに役立つ。Michael Feathers氏はその事実を疑っていない。しかしながら、彼は”表現性を求めるとき自然言語のみが考慮されるべきではない”という事を強調している。
この文章の理解の仕方がいくつかあるという事実は見落とせない。Feathers氏はナラティブ（文章）モードとシンボリック（図表）モードを比較している。
ナラティブモードにおいて私達は散文のようなテキストにアプローチし、それを英語かもしくは他の自然言語を読むのと同じように読み通します。それは私達の脳みその言語中枢をくすぐります。シンボリックモードはより視覚的なものなのです。
それゆえに表現性もまたシンボリックアプローチの方が優れており、Feathers氏はいくつかの状況においてそれは英語風のものよりも適切であることを論じている。また彼はこの二つのアプローチのチョイスに影響を与える可能性のあるたくさんのトレードオフを概説した。
Feathers氏はナラティブコードを”デベロッパによって、また彼らのために書かれたコード”よりもむしろユーザフェースツールに適していると考えている。しかしながら更に重要なことにそのチョイスは対象分野の特異性に依存している。まず始めにFeathers氏によると基準はそれほど明確にはなっていないものの、それは”定義と命名規則”がどれだけ固まっているかにかかっているようだ。
一方では、もしあなたが固定された定義と命名規則を伴う、日付や科学的単位のようなものにかかわっていたら、あなたのAPI内で自然言語を使用すると上手くいくかもしれない。定義が固まっているとDSLの機械が長時間かけてリファクタされる必要性が少なくなるのだ。もう一方では一旦定義が固まって、良く理解できたらシンボリックアプローチに向かって前進することによってたくさんの障害を取り除く事ができる。
Feathers氏はまたいくつかのドメインにおいてタスクのために言語表現を与えるのは容易ではないことを強調している。このケースにおいてシンボリッ クのオプションは”私達が自然言語を使用し慣れていたものよりも正確である”ので、”コードの解釈をスムースにさせる”。Feathers氏は自身のもう一つのブログ掲載"trade-offs of narrative vs. symbolic programming (source)"においてこのアイディアを掘り下げている。彼は作曲用の組み込みDSL内にお けるシンボリックアプローチの例を挙げた。
funkGroove
= let p1 = perc LowTom qn
p2 = perc AcousticSnare en
in Tempo 3 (Instr Percussion (cut 8 (repeatM
((p1 :+: qnr :+: p2 :+: qnr :+: p2 :+:
p1 :+: p1 :+: qnr :+: p2 :+: enr)
:=: roll en (perc ClosedHiHat 2))
)))
Feathers氏によると、シンボリックモードは”音符を聞くかもしくはページ上で見る程には音符がどのように続いているのかについてみんな気にしていな い”ので、（このような）特定の分野では上手く働くのである。もっと一般的に言うと、彼はシンボリックアプローチはナラティブモードがより適したセマンティックに関するプログラムよりも、構成に関したプログラムに向いていると論じている。
それゆえに可読性と表現性を改善するための方法として、英語風のコードを選ぶ前にある特定の要素を考慮に入れる事が大切である。あなたの経験を踏まえてあなたはシンボリックアプローチの表現力とMichael Feathers氏によって提示されたトレードオフについてどう思うだろうか？
原文はこちらです：http://www.infoq.com/news/2008/01/narrative-vs-symbolic-code
関連ニュース："Literate Testing" for Readable JUnit Tests