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

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

以下为原文：

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

剽窃即是最诚恳的恭维

——佚名

编码

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

用户界面

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

调试

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

性能

• 【程序优化第一法则】不要优化。【程序优化第二法则——进队专家适用】还是不要优化
• 对于那些快速算法，我们总是可以拿一些速度差不多但是更容易理解的算法来替代他们
• 在一些机器上，间接寻址比基址寻址要慢，所以请把结构体或者记录中最常用的成员放在最前面(这个在现今这个时代除非是核心部分，基本没有必要这么苛刻了)
• 在一个非I/O密集型的程序中，超过一半的运行时间是花在不足4%的代码上的
• 在优化一个程序之前，请先用性能监视器工具找到程序的“热点”
• 【代码规模守恒定律】当你为了加速，把一页代码编程几条简单的指令时，请不要忘了增加注释，以使源码的函数保持为一个衡量（

  标签：错误,一个,代码,编程,程序,80%,珠玑,90%,箴言
  来源： https://www.cnblogs.com/taceywong/p/10509065.html