《编程珠玑(续)》计算机科学箴言

由于搜索引擎收录及编辑问题，从https://taceywong.github.io/迁移至此.

以下为原文：

真真是字字珠玑，所以我全抄了。

剽窃即是最诚恳的恭维

——佚名

编码

• 如果好没想清楚，就用蛮力算法吧。
• 不要使用反正弦和反余弦函数——你总能用优美的恒等式，或者是计算向量点积来更好地解决这些问题.
• 在存储日期的年份的时候，请使用四位数字：千禧年快要到了。（我挺心疼日本和中国的程序员的）
• 避免不对称结构
• 代码写的越急，程序跑的越慢
• 你用英语都写不出来的东西就别指望用代码写了。（此处英语指代人话、自然语言）
• 注意细节
• 如果代码和注释不一致，那很可能两者都错了
• 如果你发现特殊情况太多，那你肯定是用错方法了
• 先把数据结构搞清楚，程序的其余部分自现（对于一个多个组件的系统，现把通信“协议”搞清楚）

用户界面

• 【最小惊异原则】尽可能让用户界面风格一致和可预测
• 计算机生成的输入通常让一个原本设计接受手工输入的程序不堪重负
• 手工填写的表单中有20%都包含坏数据
• 80%的表单会要你回答没必要的问题
• 不要染过那个户提供那些系统已知的信息
• 所有数据集的80%中，有95%的信息量都可以用清晰的图表示（对于人类大脑，有时一图胜千言）

调试

• 在我所有的程序错误中，80%是语法错误，剩下的20%里，80%是简单的逻辑错误。在剩下的4%中，80%是指针错误。只有剩余的0.8%才是困难的问题
• 在系统测试阶段找出并修正错误，要比开发者自己完成这一工作要多付出2倍的努力。而当系统已经交付使用之后找出并修正一个错误，要比系统测试阶段多付出9倍的努力，因此，请坚持让开发者进行单元测试吧。
• 不要站着调试程序，那会使得你的耐心减半，你需要的是全神贯注
• 别再注释里陷得太深——注释很可能会误导你，你要调试的知识代码
• 测试只能证明程序有错误，而不能证明程序没有错误
• 新系统的每一个新用户都可能发现一类新的错误
• 东西没坏，就别乱修
• 【维护者箴言】如果我们没能力修好它，我们就会告诉你它压根没坏
• 修正程序错误的第一步是先重现这个错误

性能

• 【程序优化第一法则】不要优化。【程序优化第二法则——进队专家适用】还是不要优化
• 对于那些快速算法，我们总是可以拿一些速度差不多但是更容易理解的算法来替代他们
• 在一些机器上，间接寻址比基址寻址要慢，所以请把结构体或者记录中最常用的成员放在最前面(这个在现今这个时代除非是核心部分，基本没有必要这么苛刻了)
• 在一个非I/O密集型的程序中，超过一半的运行时间是花在不足4%的代码上的
• 在优化一个程序之前，请先用性能监视器工具找到程序的“热点”
• 【代码规模守恒定律】当你为了加速，把一页代码编程几条简单的指令时，请不要忘了增加注释，以使源码的函数保持为一个衡量（😁哈哈😄）
• 如果程序员自己模拟实现一个构造比编译器本身实现那个构造还要快，那边一起的作者也是太失败了
• 要加速一个I/O密集型的程序，请首先考虑所有的I.O，消除那些不必要的或冗余的I/O，并使余下的部分尽可能的快（有些I/O没办法消除，起码在工程上消除会造成很大的麻烦）
• 最快的I/O就是不I/O
• 那些最便宜、最快而且可靠性最高的计算机组件压根儿就不存在
• 大多数的汇编语言都有循环操作，用一条机器指令进行一次比较并分支；尽管这条指令视为循环设计的，但在做普通的比较时往往也能听派上用场，而且很有效
• 【编译器作者箴言——优化步骤】把一个本来就错了的程序变得更糟糕绝不是你的错
• 电每纳秒传播一英尺
• Lisp程序员知道所有东西的值，却不知道那些东西的计算成本

文档

• 【否定测试】如果一句话反过来就必然不成立，那就根本没必要把这句话放进文档
• 当你试图解释一条命令、一个语言特性或是一种硬件的时候，请首先说明它要解决的问题（嗯嗯，深以为然）
• 【一页原则】一个「规格说明、设计、过程、测试计划」如果不能再一页信纸上写明白，name这个东西别人就没办法理解
• 纸上的工作没有结束，整个工作也就还没结束

软件管理

• 系统的结构反映出构建该系统的组织的结构
• 别坚持做那些没用的事
• 【90-90法则】前90%的代码占用了90%的预订开发时间，余下的10%代码又花费了90%的预订开发时间
• 只有不到10%的代码用于完成这个程序表面的目的，余下的都在处理输入和输出、数据验证、数据饥饿否维护等家务活
• 正确的判断来源于经验，然而经验来源于错误的判断
• 如果有人基本上做出了你想要做的东西，你就没必要自己写一个新程序。就算你非邪不可，也请尽可能多地利用现有的代码
• 代码能借用就借用
• 与客户保持良好的关系可以使生产率加倍
• 把一个现有成熟程序转移到一种新语言或者新平台，只需要原来开发的十分之一的时间、人力、成本
• 那些用手做就已经很快了的事情，就不要使用计算机去做了（~~~~）
• 那些能用计算机才迅速解决的问题，就别用手做了
• 我想写的程序不只是程序，而且是会写程序的程序
• 【Brooks原型定律】计划好抛弃一个原型，这是迟早的事
• 如果开始就打算抛弃一个原型，那恐怕你得抛弃两个
• 原型方法可以将系统开发的工作量减少40%
• 【Thompson望远镜学徒定律】先做一个4英尺镜片的望远镜，再做一个6英尺的镜片的，这比直接做6英尺镜片的更省时间。
• 拼命干活无法取代理解
• 做事应该先做最难的部分。如果最难的部分无法做到，那还在简单的部分上浪费时间干嘛？一旦困难的地方搞定了，那你就胜利在望了。做事应该先做最简单的部分。你开始所预想的简单部分，做起来可能是很有难度的。一旦你把简单的部分做好了，你就可以全力攻克最难的部分了

其他

• 【Sturgeon定律——在科幻小说和计算机科学中同等适用】毫无疑问，90%的软件都没什么用。这是因为对任何东西而言，其中的90%都是没什么用的
• 对计算机撒谎是要受到惩罚的
• 如果不要求系统可靠，他可能做任何事情
• 一个人的常量是另一个人的变量（呜哇呜哇）
• 一个人的数据就是另一个人的程序（哈哈哈哈）
• 【KISS法则】用最简单、最笨的方法做事（Keep it simple 、stupid）

---

• 把通常情况和最坏情况分开处理
• 在分配资源的时候，请努力避免引起灾难，而不是妄图获得最优