コードをより読みやすく明確にしたいか?Reg Braithwaite氏は、プログラミングイディオムの適切な選択はその目標達成の手段になりえると信じている。望んでいる結果を得るには、しばしばさ まざまな方法があり、その選択は無作為であってはならないと強調する。コードのインテントがビルド中のような、最も明白な方法で示すツールを選択するべき である(ブログ・英語)。たとえば、構文の選択にはコードのインテントについての有益な情報を盛り込むことが可能である。
ここで、Rubyのブロックを検討してみる。人によってはブロックが複数行を必要としている場合、do...endを使用し、それが1行でおさまる場合、 { … } を使用する。有名(AFAIK)かつ優れた考えは、主に副作用のために実行されているブロックと戻り値のために実行されているブロック間の曖昧さを、 do..endおよび{…}を使用して、取り除くことである。
foo.map { |x|
# I care about the result
}
foo.each do |x|
# I care about the side effects
endもちろんコンピュータは気にしないが、追加の情報を信号で送る。主に副作用に興味がある場合もあれば、結果に興味がある場合もあるという事実の情報である。
Braithwaite氏は、このアプローチは構文イディオムに制限されるのではなく、パラダイムにまで拡大することができると信じている。たとえば、 Rubyのような言語によっては、「言語がサポートする完全に違う考え方が存在する」。これは、実現しようとしているものに最もよく合致するパラダイムか らイディオムを借用することで、インテントを宣言する手段として使用することができる。
機能的なことを機能的に見せることで、結果を求めた計算を正確に実行しているということをはっきりと伝えることができる。forやwhileのような命令 構文を使用する際は、 変数を変化させたり、他の副作用を発生させるための時間をあらかじめ取っておく必要がある。[…] 同様に、実世界でエンティティーをモデリングしているときや、長期間持続的な状態が必要なとき、オブジェクト指向はすばらしいパラダイムとなるか? Rubyのような言語は、陰でオブジェクトを使用する必要があるが、仲間にエンティティが関わっていることを伝えようとする場合を除いて、コードはオブ ジェクト指向であるべきではない。
ときにはパラダイムの選択がこの種の決まりごとのため、パフォーマンスの要求によって課せられることは明らかであるが、可能な限りプログラマーにさらに情報を提供するようにしてコードを読みやすく表現に富んだものとする。
文書化されておらず、未検証の決まりごとを使ってはさらに混乱を招くだけだ、と論じる者もなかにはいる。しかしながらReg氏は、どんなプロジェクトにも プログラミング上のある種の決まりごとはあると言う。たとえば、Bang!メソッドの名前を使用して状態の変化を示す(sort vs. sort!)ことなどである。また、必要に応じて規定された決まりごとを文書化することを妨げるものは何もないと彼は言う。
インテントを宣言する信号や手段としてイディオムを使用することについて、どう考えるか?
原文はこちらです：http://www.infoq.com/news/2008/02/idioms-as-signals