第1章 整洁代码
什么是整洁代码？
外表或举止上令人愉悦和雅观；令人愉悦的精致和简单。——Robert C.Martin
整洁的代码应可由作者之外的开发者阅读和增补。它应当有单元测试和验收测试。——Dave Thomas，Eclipse战略教父。
第2章 有意义的命名
2.1，介绍
软件命名随处可见命名。我们给变量、函数、参数、类和封包命名。
2.2，名副其实
我们应该选择指明了计量兑现个计量单位的名称。
选择体现本意的名称能让人更容易理解和修改代码。
2.3，避免误导
别用accountList来指称一组账号，除非它真是List类型用accountGroup或者bunchOfAccounts，甚至直接用accounts都会好一些。
提防使用不同之处较小的名称。
以同样的方式拼写出同样的概念才是信息。拼写前后不一致就是误导。
误导性名称最可怕的例子使用小写字母l和大写字母O。
2.4，做有意义的区分
不要因为同一作用范围内两样不同的东西不能重名，而随手改掉其中一个的名称。
不要以数字系列命名（a1/a2/aN），这样完全没有提供正确的信息，没有提供导向作者意图的线索。
Variable一词不应当出现在变量名中。Table一词永远不应当出现在表名中。
要区别名称，就要以读者能鉴别不同之处的方式来区分。
2.5，使用读得出来的名称
2.6，使用可搜索的名称
单字母和数字常量有个问题，就是很难再一大篇文字中找出来。
名称长短应与其作用域大小相对应。
2.7，避免使用编码
带编码的名称通常不便发音，容易打错。
不必要使用m_前缀来标明成员变量。应当把类和函数坐的足够小，消除对成员前缀的需要。
2.8，避免思维映射
不应当让读者在脑中把你的名称翻译为他们熟知的名称。这种问题经常出现在选择是使用问题领域术语还是解决方案领域术语时。
2.9，类名
类名和对象名应该是名词或名词短语。
类名不应该是动词。
2.10，方法名
方法名应当是动词或动词短语，依据Javabean标准加上get、set和is前缀。
2.11，别扮可爱
扮可爱的做法在代码中经常体现为使用俗语或者俚语。
2.12，每个概念对应一个词
使用一以贯之的命名法
2.13，别用双关语
避免将同一个单词用于不同目的。
2.14，使用解决方案领域名称
尽管用那些计算机科学术语、算法名、模式名、数学术语。
2.15，使用源自所涉及问题领域的名称
优秀的程序员和设计师，其工作之一就是分离解决方案领域和问题领域的概念。与所涉及问题领域更贴近的代码，应当采用源自问题领域的名称。
2.16，添加有意义的语境
需要有良好的命名的类、函数或者命名空间来放置名称，给读者提供语境。
2.17，不要添加没用的语境
只要短名称足够清楚，就要比长名称好。别给名称添加不必要的语境。
2.18，最后的话
取号名字最难的地方在于需要良好的描述技巧和工友文化背景。
第3章 函数
在编程的早年岁月中，系统由程序和子程序组成。后来，在Fortran和PL/1的年代，系统由程序、子程序和函数组成。如今，只有函数存活下来。函数是所有程序中的第一组代码。
是什么让代码易于阅读和理解？怎么才能让函数表达其意图？该给函数赋予哪些属性，好让读者一看就明白函数是属于怎样的程序呢？
3.1，短小
函数的第一规则是短小。
3.2，只做一件事
函数应该做一件事。做好一件事。只做一件事。
3.3，每个函数一个抽象层级
自顶向下读代码：向下规则
3.4，switch语句
将switch语句埋到抽象工厂底下，不让任何人看到。
3.5，使用描述性的名称
长而具有描述性的名称，要比短而令人费解的名称好。
命名方式要保持一致。使用与模块名一脉相承的短语、名词和动词给函数命名。
3.6，函数参数
最理想的参数数量是零（零参数函数），其次是一（单个参数函数），再次是二（双参数函数），应尽量避免三（三参数函数）。有足够特殊的理由才能用三个以上参数（多参函数）——无论如何也不要这么做。
3.7，无副作用
应避免使用输出参数。如果函数必须修改某种状态，就修改所属对象的状态吧。
3.8，分隔指令与询问
函数要么做什么事，要么回答做什么事，但二者不可得兼。函数应该修改某对象的状态，或是返回改对象的相关信息。两样豆干常会导致混乱。
3.9，使用异常替代返回错误码
从指令式函数返回错误码轻微违反了指令与询问间隔的规则。它鼓励了在if语句判断指令当做表达式使用。
这不会引起动词/形容词混淆，但却导致更深层次的嵌套结构。当返回错误码时，就是在要求调用者立刻处理错误。
另一方面，如果使用异常替代返回错误码，错误处理代码就能从主路径代码中分离出来，得到简化。
3.10，别重复自己
重复可能是软件zho9ng一切邪恶的根源。许多原则与实践规则都是为控制与消除重复而创建。
3.11，结构化编程
关系数据库之父Dijkstra认为，每个函数、函数中的每个代码块都应该有一个入口、一个出口。遵循这些原则，意味着在每个函数中只该有一个return语句，循环中不能有break或continue语句，而且永永远远不能有任何goto语句。
只有在大函数中，这些规则才会有明显的好处。
所以，只要函数保持短小，偶尔出现的return、break或continue语句没有坏处，甚至还比单入单出原则更具表达力。另一方面，goto只在大函数中才有道理，所以应该尽量避免使用。
3.12，如何写出这样的函数
打磨代码、分解函数、修改名称、消除重复、缩短和重新安置方法、拆散类、写单元测试。
3.13，小结
大师级别程序员把系统当做故事来讲，而不是当做程序来写。
第4章 注释
若编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释——也许根本不需要。
4.1，注释不能美化糟糕的代码
带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎而复杂的代码像样得多。与其花时间编写解释你高出糟糕代码的注释，不如花时间清洁那堆糟糕的代码。
4.2，用代码阐述
用代码解释你大部分的意图。
4.3，好注释
唯一真正好的注释是你想办法不去写的注释。
4.4，坏注释
通常，坏注释都是糟糕的代码的支撑或借口，或者对错误决策的修正，基本等于程序员自说自话。
第5章 格式
5.1，格式的目的
代码风格和可读性会影响到可维护性和扩展性。即便代码已不复存在，你的风格和律条仍存活下来。
5.2，垂直格式
向报纸学习
源代码文件该有多大？
5.3，横向格式
一行代码应该有多宽？
5.4，团队规则
一组开发者应当认同一种格式风格，每个成员都应该采用那种风格。