计算机科学箴言集
《编程珠玑》，字字珠玑，发人深省，细细读来，内力必然精进，倾情推荐。
书中一章专门写的多年来无数先驱们对软件开发的经验总结，十分精辟，列出如下。
编码
如果还没想清楚，就用蛮力算法吧。
——Ken Thompson，贝尔实验室
不要使用反正弦和反余弦函数——你总能用优美的恒等式，或者是计算向量点积来更好地解决这些问题。
——Jim Conyngham，Arvin/Calspan高级技术中心
在存储日期中的年份的时候，请使用四位数字：千禧年快要到了。
——David Martin，宾夕法尼亚州诺里斯敦
避免不对称结构。
——Andy Huber，Data General公司
代码写得越急，程序跑得越慢。
——Roy Carlson，威斯康星大学
你用英语都写不出来的东西就别指望用代码写了。
——Peter Halpern，纽约州布鲁克林
注意细节。
——Peter Weinberger，贝尔实验室
如果代码和注释不一致，那很可能两者都错了。
——Norm Schryer，贝尔实验室
如果你发现特殊情况太多，那你肯定是用错方法了。
——Craig Zerouni，Computer FX公司（英国伦敦）
先把数据结构搞清楚，程序的其余部分自现。
——David Jones，荷兰阿森
用户界面
【最小惊异原则】尽可能让用户界面风格一致和可预测。
——几位读者提出
计算机生成的输入通常会让一个原本设计接受手工输入的程序不堪重负。
——Dennis Ritchie，贝尔实验室
手工填写的表单中有20%都包含坏数据。
——Vic Vyssotsky，贝尔实验室
80%的表单会要你回答没有必要的问题。
——Mike Garey，贝尔实验室
不要让用户提供那些系统已经知道的信息。
——Rick Lemons，Cardinal数据系统公司
所有数据集的80%中，有95%的信息量都可以用清晰的图表示。
——William S. Cleveland，贝尔实验室
调试
在我所有的程序错误中，80%是语法错误。剩下的20%里，80%是简单的逻辑错误。在剩下的4%里，80%是指针错误。只有余下的0.8%才是困难的问题。
——Marc Donner，IBM沃森研究中心
在系统测试阶段找出并修正错误，要比开发者自己完成这一工作多付出2倍的努力。而当系统已经交付使用之后找出并修正一个错误，要比系统测试阶段多付出9倍的努力。因此，请坚持让开发者进行单元测试吧。
——Larry Bernstein，贝尔通信研究院
不要站着调试程序。那会使得你的耐心减半，你需要的是全神贯注。
——Dave Storer，艾奥瓦州锡达拉皮兹
别在注释里陷得太深——注释很可能会误导你的，你要调试的只是代码。
——Dave Storer，艾奥瓦州锡达拉皮兹
测试只能证明程序有错误，而不能证明程序没有错误。
——Edsger W. Dijkstra，得克萨斯大学
新系统的每一个新用户都可能发现一类新的错误。
——Brian Kernighan，贝尔实验室
东西没坏，就别乱修。
——罗纳德•里根，加州圣巴巴拉
【维护者箴言】如果我们没能力修好它，我们就会告诉你它根本就没坏。
——Walt Weir，美国陆军中校
修正程序错误的第一步是要先重现这个错误。
——Tom Duff，贝尔实验室
性能
【程序优化第一法则】不要优化。
【程序优化第二法则——仅对专家适用】还是不要优化。
——Michael Jackson，Michael Jackson系统公司
对于那些快速算法，我们总是可以拿一些速度差不多但是更容易理解的算法来替代它们。
——Douglas W. Jones，艾奥瓦大学
在一些机器上，间接寻址比基址寻址要慢，所以请把结构体或记录中最常用的成员放在最前面。
——Mike Morton，马萨诸塞州波士顿
在一个非I/O密集型的程序中，超过一半的运行时间是花在不足4%的代码上的。
——Don Knuth，斯坦福大学
在优化一个程序之前，请先用性能监视工具找到程序的“热点”。
——Mike Morton，马萨诸塞州波士顿
【代码规模守恒定律】当你为了加速，把一页代码变成几条简单的指令时，请不要忘了增加注释，以使源码的行数保持为一个常量。
——Mike Morton，马萨诸塞州波士顿
如果程序员自己模拟实现一个构造比编译器本身实现那个构造还要快，那编译器的作者也太失败了。
——Guy L. Steele, Jr.，Tartan实验室
要加速一个I/O密集型的程序，请首先考虑所有的I/O。消除那些不必要的或冗余的I/O，并使余下的部分尽可能地快。
——David Martin，宾夕法尼亚州诺里斯敦
最快的I/O就是不I/O。
——Nils-Peter Nelson，贝尔实验室
那些最便宜、最快而且可靠性最高的计算机组件压根儿就不存在。
——Gordon Bell，Encore计算机公司
大多数的汇编语言都有循环操作，用一条机器指令进行一次比较并分支；尽管这条指令是为循环设计的，但在做普通的比较时往往也能派上用场，而且很有效。
——Guy L. Steele, Jr.，Tartan实验室
【编译器作者箴言——优化步骤】把一个本来就错了的程序变得更糟绝不是你的错。
——Bill McKeeman，王安公司
电每纳秒传播一英尺。
——Grace Murray Hopper，美国海军准将
Lisp程序员知道所有东西的值，却不知道那些东西的计算成本。
——Alan Perlis，耶鲁大学
文档
【否定测试】如果一句话反过来就必然不成立，那就根本没必要把这句话放进文档。
——Bob Martin，AT&T公司
当你试图解释一条命令、一个语言特性或是一种硬件的时候，请首先说明它要解决什么问题。
——David Martin，宾夕法尼亚州诺里斯敦
【一页原则】一个{规格说明、设计、过程、测试计划}如果不能在一页8.5英寸×11英寸的纸上写明白，那么这个东西别人就没办法理解。
——Mark Ardis，王安公司
纸上的工作没结束，整个工作也就还没结束。
——佚名
软件管理
系统的结构反映出构建该系统的组织的结构。
——Richard E. Fairley，王安公司
别坚持做那些没用的事。
——佚名
【90—90法则】前90%的代码占用了90%的预定开发时间，余下的10%代码又花费了90%的预定开发时间。
——Tom Cargill，贝尔实验室
只有不到10%的代码用于完成这个程序表面上的目的，余下的都在处理输入输出、数据验证、数据结构维护等家务活。
——Mary Shaw，卡内基—梅隆大学
正确的判断来源于经验，然而经验来源于错误的判断。
——Fred Brooks，北卡罗来纳大学
如果有人基本上做出了你想要做的东西，你就没必要自己写一个新程序。就算你非写不可，也请尽可能多地利用现有的代码。
——Richard Hill，惠普公司（瑞士日内瓦）
代码能借用就借用。
——Tom Duff，贝尔实验室
与客户保持良好的关系可以使生产率加倍。
——Larry Bernstein，贝尔通信研究院
把一个现有成熟程序转移到一种新语言或者新平台，只需要原来开发的十分之一的时间、人力、成本。
——Douglas W. Jones，艾奥瓦大学
那些用手做就已经很快了的事情，就不要用计算机去做了。
——Richard Hill，惠普公司（瑞士日内瓦）
那些能用计算机迅速解决的问题，就别用手做了。
——Tom Duff，贝尔实验室
我想写的程序不只是程序，而且是会写程序的程序。
——Dick Sites，DEC公司
【Brooks原型定律】计划好抛弃一个原型，这是迟早的事。
——Fred Brooks，北卡罗来纳大学
如果开始就打算抛弃一个原型，那恐怕你得抛弃两个。
——Craig Zerouni，Computer FX公司（英国伦敦）
原型方法可以将系统开发的工作量减少40%。
——Larry Bernstein，贝尔通信研究院
【Thompson望远镜学徒定律】先做一个4英尺镜片的（望远镜），再做一个6英尺镜片的，这比直接做6英尺镜片的更省时间。
——Bill McKeeman，王安公司
拼命干活无法取代理解。
——H. H. Williams，加州奥克兰
做事应该先做最难的部分。如果最难的部分无法做到，那还在简单的部分上浪费时间干嘛？一旦困难的地方搞定了，那你就胜利在望了。
做事应该先做最简单的部分。你开始所预想的简单部分，做起来可能是很有难度的。一旦你把简单的部分都做好了，你就可以全力攻克最难的部分了。
——Al Schapira，贝尔实验室
其他
【Sturgeon定律——在科幻小说和计算机科学中同等适用】毫无疑问，90%的软件都没什么用。这是因为对任何东西而言，其中的90%都是没什么用的。
——Mary Shaw，卡内斯—梅隆大学
对计算机撒谎是要受到惩罚的。
——Perry Farrar，马里兰州
如果不要求系统可靠，它可能做任何事情。
——H. H. Williams，加州奥克兰
一个人的常量是另一个人的变量。
——Susan Gerhart，Microelectronics and Computer Technology公司
一个人的数据就是另一个人的程序。
——Guy L. Steele, Jr.，Tartan实验室
【KISS法则】用最简单、最笨的方法做事。（keep it simple, stupid）
——佚名
原理
看到这里，你一定会接受下面这条不错的箴言：
别轻信那些看似聪明的法则。
——Joe Condon，贝尔实验室
