如何判断一段程序是否优美？

我喜欢的美好的东西，看似相隔很远，比如写文章，学习西班牙语，绘画，还有编程，却有着相同的本质 -- 使用一种简练的最基本的元素构建一个世界。可以像文章一样被读懂，西班牙语一样被听懂，像绘画一样被人看到，像程序一样被执行。

Paul Graham 写过一本书《黑客与画家》，细致精确的描述了绘画和编程的相似之处，他把程序员，画家，作家，建筑师，作曲家的本质提炼出来，称之为 maker - 就是建造者。

我是一个从骨子里面喜欢建造的人。这就是我如此喜欢写作，喜欢学习语言，喜欢绘画，并且喜欢编程的本质。

对于今天问自己的这个问题：如何判断一段程序是否优美？在有可能想到的所有的指标中，我毫不犹豫的断言，就是看完成同样的工作，越短的代码，就是越美的。

在我创业和架构程序的过程中，我曾经信奉 帕斯卡 的一句名言：“我亲爱的朋友，如果我有更多的时间，我就可以给你写更短的信 ”。几百年后马克吐温也说了类似的话：“我实在没有时间写一封短信，所以我写了封长信给你”。  

抽象，封装

对于程序更加如此。如果有时间，建构者总可以找出更好的抽象，更好的封装从而大幅度的减少代码的长度，并且代码会变得更加清新，更加美丽。

简单的例子，初级的程序员会用

print(0)
print(1)
print(2)
print(3)
....
print(99)

一边加班写，一遍抱怨工作量大，而且还经常这里少了个数那里多了个数，把更多的时间花在修bug上，而高级一点的至少会用

for i in range(0, 100)
  print(i)

代码量减少但是功能并没有减少。但大多数的程序员都停留在了会用判断（ if .. else )，循环( for )为止，更加通用的封装，设计模式等都还远远没有进入大家的视野，所以写出来的代码好长好长，比写代码更痛苦的是看这些代码，味如嚼蜡。按我的经验，一般来说写出来的第一遍代码，如果花时间重构和改进，打磨好的代码一般可以减少到 一半 甚至 1/3 以下的代码量。体系规模越大，压缩的比例越大。

曾经听很多公司炫耀自己有几百万行的代码，其实作为有品位的程序员，对代码的长度是有洁癖的。我们曾经技术团队每天要发一个报表，把每个人写的代码长度排名的，代码量最大的一个需要停下来重构程序，直到把巨长的代码重构到第二名以后才可以继续开发新的功能。实验证明，这总是可行的。

眼界

同时代码的长度也基本上代表了一个程序员的眼界高低。在浩如烟海一般的程序库里面，通常已经有一些可以完成相同功能的函数，甚至是内置语法，使用这些语法，就可以用一个函数省去很多行代码。这就像会使用成语，典故的人写出来的文章，就是可以用少得多的字描绘出精准的多的意境。

语言也是函数

想到这里，我们随便举个英语学习的例子。不知道大家是否也和我注意到语言的函数嵌套性。look 是看的意思。如果词汇不够，说到“盯”这个意思，就只能一次一次的用 look fixedly 这两个词，而不会用 stare 这个难一点的词；而要表达出与惊讶的凝视，就只会用 stare in suprise ，而更优美的说法就是

 gaze 。。。。如果不知道 gaze ，就会写出这样的语句：I looked at him fixedly in suprise. 

每一个单词就是一个函数，是前面的简单的语义加上形容，组合，转意以后形成的一个新的概念，并且定义为新的函数。东施效颦，夜郎自大，名落孙山，掩耳盗铃 等等成语甚至把一个故事浓缩成了四个字。使用这个成语就可以省去几百字的过程描述。合理的使用这样的历史上定义过的函数的语言，是美的。

程序有着比语言容易得多的扩展性。现代语言如果想发展，有着巨大的惯性，现代要发明一个成语，不仅需要有人创造，而且要有巨大的力量（例子：这里是不是改成洪荒之力可以少一个字但是表达了形象的多的意境呢？）才能让整个社会都学会这个新函数。而程序里面自己可以随时定义新的函数，定义以后立刻就可以使用，所以制约程序员写更短的代码的，就只有程序员的思维能力和见识了。

之所以有此感触，就是因为今天读到了 anime.js 这个只有1000行代码的 JavaScript 动画库。它用了几行就实现了让我难以想象的复杂算法和功能。读起来如小说般引人入胜，甚至有的时候会心跳加快。深深的感慨，一个优美的程序就是这样可以用最短的语句表达尽量多的功能，同时体现出令人惊讶的美感。