01、排版问题
程序是一种出版物。意味着程序员们会先阅读，最后才轮到机器。机器的快乐就是程序能编译，机器才不在乎程序写的有多么漂亮，可是人们应该保持程序的美观。有时人们会过度关心：用漂亮的打印机呆板地打印出漂亮的输出，而这些输出只是将所有介词用英文文本以粗体字体凸显出来，都是些与程序无关的细节。虽然有很多人认为程序就应该像 Algol.68 所描述的一样（有些系统甚至要求照搬该风格编写程序），可清晰的程序不会因为这样的呈现而变得更清晰，只会使糟糕的程序变得更可笑。
对于清晰的程序来说，排版规范一向都是至关重要的。当然，众所周知最有用的是缩进，但是当墨水遮盖了意图时，就会控制住排版。因此即便坚持使用简单的旧打字机输出，也该意识到愚蠢的排版。避免过度修饰，比如保持注释的简洁和灵活。通过程序整齐一致地说出想表达的。接着往下看。
02、变量命名
对于变量名称，长度并不是名称的价值所在，清晰的表达才是。不常用的全局变量可能会有一个很长的名称，像 maxphysaddr。在循环中每一行所使用的数组索引，并不需要取一个比 i 更详尽的名字。取 index 或者 elementnumber 会输入更多的字母（或调用文本编辑器），并且会遮盖住计算的细节。当变量名称很长时，很难明白发生了什么。
03、指针的使用
C语言不同寻常，因为它允许指针指向任何事物。指针是锋利的工具，像任何这样的工具一样，使用得当可以产生令人愉悦的生产力，但使用不当也可以造成极大的破坏。指针在学术界的名声不太好，因为它太危险了，莫名其妙地就变得糟糕的不行。但我认为它是强大的符号，它可以帮助我们清楚地自我表达。
04、过程名称
过程名称应该表明它们是做什么的，函数名称应该表明它们返回什么。函数通常在像 if 这样的表达式使用，因此可读性要好。
05、注释
这一个微妙的问题，需要自己体会和判断。由于一些原因，我倾向于宁可清除注释。第一，假如代码清晰，并且使用了规范的类型名称和变量名称，应该从代码本身就可以理解。第二，编译器不能检查注释，因此不能保证准确，特别是代码修改过以后。误导性的注释会非常令人困惑。第三，排版问题：注释会使代码变得杂乱。
但有时我会写注释，像下文一样仅仅只是把它们用于介绍。例如：解释全局变量的使用和类型（我总是在庞大的程序中写注释）；作为一个不寻常或者关键过程的介绍；或标记出大规模计算的一节。
06、复杂度
许多程序过于复杂，比需要有效解决的问题更加复杂。这是为什么呢？大部分是由于设计不好，但我会跳过这个问题，因为这个问题太大了。然而程序往往在微观层面就很复杂，有关这些可以在这里解决。
▪ 规则 1：不要断定程序会在什么地方耗费运行时间。瓶颈总是出现在令人意想不到的地方，直到证实瓶颈在哪，不要试图再次猜测并加快运行速度。
▪ 规则 2：估量（measure） 在没有对代码做出估量之前不要优化速度，除非发现最耗时的那部分代码，要不也不要去做。
▪ 规则 3：当 n 很小时（通常也很小），花哨的算法运行很慢。花哨算法有很大的常数级别复杂度。在你确定 n 总是很大之前， 不要使用花哨算法。（即使假如 n 变大，也优先使用规则 2）.例如，对于常见问题，二叉树总比伸展树高效。
▪ 规则 4：花哨的算法比简单的算法更容易有 bug，而且实现起来也更困难 尽量使用简单的算法与简单的数据结构。
以下几乎是所有实际程序中用到的数据结构：
▪ 数组
▪ 链表
▪ 哈希表
▪ 二叉树
当然也必须要有把这些数据结构灵活结合的准备，比如用哈希表实现的符号表，其中哈希表是由字符型数组组成的链表。
▪ 规则 5：以数据为核心 如果选择了适当的数据结构并把一切都组织得很有条理性，算法总是不言而喻的。编程的核心是数据结构，而不是算法。（参考 Brooks p. 102）
▪ 规则 6：就是没有规则 6。
07、数据编程
不像许多 if 语句，算法或算法的细节通常以紧凑、高效和明确的数据进行编码。眼前的工作可以编码，归根到底是由于其复杂性都是由不相干的细节组合而成。分析表是典型例子，它通过一种解析固定、简单代码段的形式，对编程语言的语法进行编码。有限状态机特别适合这种处理形式，但是几乎任何涉及到对构建数据驱动算法有益的程序，都是将某些抽象数据类型的输入“解析”成序列，序列会由一些独立“动作”构成。
也许这种设计最有趣的地方是表结构有时可以由另一个程序生成（经典案例是解析生成器）。有个更接地气的例子，假如操作系统是由一组表驱动，这组表包含连接 I/O 请求到相应设备驱动的操作，那么可以通过程序“配置“系统，该程序可以读取到某些特殊设备与可疑机器连接的描述，并打印相应的表。
数据驱动程序在初学者中不常见的原因之一是由于 Pascal 的专制。Pascal 像它的创始人一样，坚信代码要和数据分开。因而（至少在原始形式上）无法创建初始化的数据。与图灵和冯诺依曼的理论背道而驰，这些理论可都是定义存储计算机的基本原理。代码和数据是一样的，或至少可以算是。还能怎样解释编译器的工作原理呢？（函数式语言对 I/O 也有类似的问题）
08、函数指针
Pascal 专制的另一个结果是初学者不使用函数指针。（在 Pascal 中没有把函数作为变量） 用函数指针来处理编码复杂度会有一些令人感兴趣的地方。
指针指向的程序有一定的复杂度。这些程序必须遵守一些标准协议，像要求一组都是相同调用的程序就是其中之一。除此之外，所要实现的只是完成业务，复杂度是分散的。
有个协议的主张是既然所有使用的功能相似，那么它们的行为也必须相似。这对简单的文档、测试、程序扩展和甚至使程序通过网络分布都有帮助——远程过程调用可以通过该协议进行编码。
我认为面相对象编程的核心是清晰使用函数指针。规定好要对数据执行的一系列操作，以及对这些操作响应的整套数据类型。将程序合拢到一起最简单的方法是为每种类型使用一组函数指针。简而言之，就是定义类和方法。当然，面向对象语言提供了更多更漂亮的语法、派生类型等等，但在概念上几乎没有提出额外的东西。
数据驱动程序与函数指针的结合，变成了一种表现令人惊讶的工作方法。根据我的经验，这种方法经常会产生惊喜的结果。即使没有面向对象语言，无需额外的工作也可以获得 90％ 的好处，并且能更好地管理结果。我无法再推荐出更高标准的实现方式。我所有的程序都是由这种方式组织管理，而且经过多次开发后都相安无事——远远优于缺少约束的方法。也许正如所说：从长远来看，约束会带来丰厚的回报。