是不是在努力使代码更清晰易读？Reg Braithwaite 坚信，通过恰当选择程序语言的惯用语有利于表达代码的意图。他强调，尽管有多种方式实现这一目标，但我们不能随意选择，而应该选择最易于表达代码意图的方式。例如，选择适当的语法有助于传达关于代码意图的有用信息：

以 Ruby 中的代码块为例。当一个代码块包含多行代码时，一些人使用 do … end，而当只有一行代码时就只用{…}。目前就我所知，一个流行且被认可的用法就是：针对重点关注执行的“副作用”的代码块使用“do…end”，针对重点关注返回值的代码块使用{…}： foo.map { |x|

我关心执行结果

}
foo.each do |x|

我关心副作用

end 尽管计算机并不在意这些，但这段代码的确传达出一些额外的信息。事实上，在第一段代码中，我们主要关心它的结果值，而后一段代码中则是它执行的一系列“副作用”操作。

Braithwaite 认为，这种方法并不限于程序语言的语法，同样可以扩展到范式（译注：paradigm，一类典型的编程风格）上。某些语言（例如 Ruby）支持“同一个功能可以使用多种完全不同的表达方式”。这样就可以尝试选择一个最佳范式来表达代码意图。

让某个功能模块看上去就是该功能，你就可以清晰表明这段代码是严格为要达成的结果所开发的。 像 for 和 while 之类“语气较重”的命令式语法元素，应该用在需要修改变量的值或者想引发“副作用”操作的情形下。……同样地，而当你为现实世界的实体进行建模或需要长期的持久化状态时，面向对象（OO）是极佳的范式选择。象 Ruby 这样的语言，在一般情况下，会迫使你以不明显的方式使用 OO 式编程；除非你想让同事知道用到了实体对象，否则你的代码看上去不可能象是“面向对象”的代码。

尽管有时使用这种方式可能会影响性能，但是尽可能使用这种约定可以为程序员提供额外的信息使代码更易读懂，意图表达得更清晰。

一些人认为，使用无文档且未校验过的约定可能会导致更多的混乱。然而，Reg 指出，任何一个项目都会有某些编程约定，例如“使用 Bang! 这个方法名来表示状态发生了变化（比如 sort 和 sort!）”；而且如有必要，团队也会写文档来记录建立好的编程约定。

对于在代码中使用惯用语作为标记来表达意图，您怎么想？

英文原文链接： Communicating Intent through Idiom and Paradigm Selection