Doug Mcilroy:

  1. 让每个程序就做好一件事。如果有新任务,就重新开始,不要往原程序中加入新功能而搞得复杂。
  • 假定每个程序的输出都会成国另一个程序的输入,哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。

  • 尽可能早地将设计和编译的软件投入试用,哪怕是操作系统也不例外,理想情况下,应该是在几星期之内。对拙劣的代码别犹豫,扔掉重写。

  • 优先使用工具而不是拙劣的帮助来减轻编程的负担。工欲善其事,必先利其器。

  • 一个程序只做一件事,并做好。程序要能协作。程序要能处理文本流,因为这是最通用的接口。

Rob Pike:

  1. 你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方,所以别急于胡找个地方改代码,除非你已证实那儿就是瓶颈所在。
  • 估量。在你没对代码进行估量,特别是没找到最耗时的那部分之前,别去优化速度。

  • 花哨的算法在n很小时通常很慢,而n通常很小。花哨算法的常数复杂度很大。除非你确定n总是很大,否则不要用花哨算法(即使n很大,也优先考虑第2条)

  • 花哨的算法比简单算法更容易出bug、更难实现。尽量使用简单的算法配合简单的数据结构。

  • 数据压倒一切。如果已经选择了正确的数据结构并具把一切都组织得井井有条,正确的算法也就不言自明。编程的核心是数据结构,而不是算法。

给我看流程图而不让我看(数据)表,我仍会茫然不解;如果给我看(数据)表,通常就不需要流程图了;数据表足够说明问题了。

  • 原则6:没有原则6

Ken Thompson:

  1. 模块原则:使用间洁的接口拼合简单的部件。
  • 清晰原则:清晰胜于机巧。

拿不准就穷举。

  • 组合原则:设计时考虑拼接组合。

  • 分离原则:策略同机制分离,接口同引擎分离。

  • 简洁原则:设计要简洁,复杂度能低则低。

  • 吝啬原则:除非确无它法,不要编写宠大的程序。

  • 透明性原则:设计要可见,以便审查和调试。

  • 健壮原则:健壮源于透明与简洁。

  • 表示原则:把知识叠入数据以求逻辑质朴与健壮。

  • 通俗原则:接口设计避免标新立异。

  • 缄默原则:如果一个程序没什么好说的,就沉默。

  • 补救原则:也现异常时,马上退也并给出足够错误信息。

  • 经济原则:宁花机器一分钟,不花程序员一秒钟。

  • 生成原则:避免手工hack,尽量编写程序去生成程序。

  • 优化原则:雕琢前先要有原型,跑之前先学会走。

  • 多样原则:决不相信所谓“不二法门”的断言。

  • 扩展原则:设计着眼未来,未来部比预想来得快。