代码会因近似英语而变得更好吗?

  • Sadek Drobi
  • 王丽娟

2008 年 1 月 21 日

话题:架构语言 & 开发

通过编写像英语的代码来实现可读性和表达力,在当今业界是呈上升趋势的。在 DSL(Domain Specific Languages)和 BDD(Behavior Driven Development)社区中尤其如此,而许多 Java、C#、Ruby 开发人员也在设法让自己的代码看上去尽可能地近似英语。

Michael Feathers在他的文章《叙述的冲动》中挑战了“代码因近似英语而变得更好”的观点。正如 Martin Fowler 和 Neal Ford 在他们关于 DSLs 的介绍中强调的一样,表达力和可读性有利于提高可维护性、增进程序员对业务的理解。Michael Feathers 并不怀疑这一事实。但是,他强调,“我们追求表达力的时候,自然语言不应该是唯一的探索方向”。

文本可以有很多不同的理解方式,这是一个不能忽视的事实。Feathers 比较了叙述模式和符号模式:

叙述模式里,我们处理像散文似的文本,并用阅读英语或其它自然语言的方式来阅读它——这取悦了我们大脑中的语言中枢。而符号模式则比较形象化。

因此,也可以用符号方式来产生表达力,Feathers 指出,在某些情况下,符号方式可能比类英语的方式更为合适。他概括了会影响到对方法的选择的若干折衷因素。

Feathers 认为叙述模式更适合于面向用户的工具,而不适合“由程序员编写和供程序员阅读的代码”。但是,更重要的是,这个选择取决于领域的特性。根据 Feathers 的意思,首先,它可能取决于“定义和术语系统有多成熟”,尽管判断的标准不那么清晰:

一方面,如果你面对的是像日期或者科学单位这样的领域,它们的定义和术语系统是很明确的,那么在你的 API 中使用自然语言会比较有利。当定义明确后,DSL 体系进行大的重构的机会是很少的。另一方面,一旦定义明确下来并得到充分的理解,这时转向符号方式可以帮你消除大量的 cruft(译注:随着软件的发展,以及经历了修改Bug和重构的若干周期之后,软件的部分代码已不再使用,但这些代码仍然保留在源码中,这种代码称为cruftcruft可能是一两行无用的代码,也可能是整个源文件模块)。

Feathers 也强调说,在一些领域,用文字表述一项任务并不容易。在这种情况下,符号表示可以“使代码理解变得轻而易举”,因为它“比我们使用的自然语言更精确”。在他的另外一篇帖子《叙述与符号编程的利弊权衡》中,Feathers 进一步强化了这一思想。他给出了一个符号方式的例子,是针对音乐作曲的嵌入式 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 介绍的符号方式的表达能力和不同的利弊之权衡,你有什么经验呢?


相关新闻:"Literate Testing" for Readable JUnit Tests

查看英文原文Does code become better as it approaches English?

架构语言 & 开发