需求描述
第一章：整洁代码
要有代码
代码呈现了需求的细节，将需求明确到机器可以执行的细节程度
糟糕的代码
不要产生糟糕的、混乱的代码，勒布朗法则：稍后等于永不
混乱的代价
花时间保持代码整洁不但有关效率，还有关生存。
我们与项目的规划脱不了关系，对失败负有极大的责任，特别是当失败与糟糕的代码有关时尤其如此。
制造混乱无益于赶上期限，做得快的唯一方法就是始终保持代码整洁。
什么是整洁代码
（1）优雅、高效；代码逻辑直截了当，缺陷难以隐藏；
（2）尽量减少依赖关系，使之便于维护
（3）依据某种分层策略完善处理错误代码
（4）整洁代码只做好一件事
（5）整洁的代码简单直接，如同优美的散文（可读性：如同一本好小说般，整洁代码应当明确地）
（6）应可有作者之外的开发者阅读和增补，应当有单元测试和验收测试
简单代码
（1）能通过所有测试
（2）没有重复代码
（3）体现系统中的全部设计理念
（4）包括尽量少的实体，比如类、方法、函数等
完善错误代码处理
在细节上多花心思
整洁的代码力求集中，每个函数，每个类和每个模块都全神贯注于一事，完全不受四周细节的干扰和污染。
总结
（1）能通过所有测试
（2）没有重复代码
（3）体现系统中的全部设计理念
（4）包含尽量少的实体，比如类、方法、函数等
不要重复代码，只做一件事，表达力，小规模抽象
#第二章：有意义的命名
（1）如果名称需要注释来补充，那就不算是名副其实（之前出现过争议）
（2）不要使用意义含糊的废话，如果名称相同但是意义不同，那么info和data与a an the一样毫无意义，varable不应出现在变量中，table不应出现在表中
（3）使用读得出来的名称，方便阅读
（4）使用方便搜索的名称
（5）避免使用编码
（6）应当把类和函数做得足够小，消除对成员前缀的需要，读代码的人通常不会读前缀
（7）不要在类名中使用奇怪的命名
（8）不要使用双关语
函数
（1）函数应该尽可能小，20行封顶最佳
（2）每个函数都一目了然，每个函数都只说一件事，每个函数都依次带到下一个函数
（3）函数的缩进层不应该多余一层或两层
需要遵循的原则
（1）确保每隔switch函数都埋藏在较低的抽象层而且永远不重复
（2）不要向函数传入布尔值（我以前经常这么做），因为传入布尔值表示函数会有多余的操作
（3）使用异常代替返回错误码（错误代码能从主路径代码中分离出来得到简化）
（4）抽离try/catch代码块
（5）不要重复自己
注释
注意
注释存在的时间越久，就离它所描述的代码越远，越来越变得全然错误，因为程序员不能坚持维护注释
必要的注释（好的注释）
（1）法律信息
（2）提供信息的注释
（3）对意图的解释
（4）阐释（如果参数或返回值是某个标准库的一部分或者不能修改的代码，帮助阐释其含义的代码就会有用）
（5）警示