第1章 整洁代码
第2章 有意义的命名
2.2 名副其实
2.3 避免误导
2.4 做有意义的区分
2.5 使用读的出来的名称
2.6 使用可搜索的名称
2.7 避免使用编码
2.8 避免思维映射
2.9 类名
2.10 方法名
2.11 别扮
2.12 每个概念对应一个词
2.13 别用双关语
2.14 使用解决方案领域名称
2.15 使用源自所涉问题领域的名称
2.16 添加有意义的语境
2.17 不要添加没用的语境
第3章 函数
3.1 短小
3.2 只做一件事
3.3 每个函数一个抽象层级
3.4 swtich语句
3.5 使用描述性的名称
3.6 函数参数
3.7 无副作用
3.8 分隔指令与询问
3.9 使用异常替代返回错误码
3.10 别重复自己
3.11 结构化编码
第4章 注释
4.1 注释不能美化糟糕的代码
4.2 用代码来阐述
4.3 好注释
4.4 坏注释
第5章 格式
第6章 对象和数据结构
第7章 错误处理
7.1 使用异常而非返回码
7.2 先写Try-Catch-Finally语句
第8章 边界
第9章 单元测试
第10章 类
第11章 系统
第12章 跌进
第13章 并发编程
第14章 逐步改进
第15章 JUint内幕
第16章 重构SerialDate
第17章 味道与启发
17.1 注释
c1:不恰当的信息
c2:废弃的注释
c3:冗余注释
c4:糟糕的注释
c5:注释掉的代码
17.2 环境
e1:需要多步才能实现的构建
e2:需要多步才能做到的测试
17.3 函数
f1:过多的参数
f2:输出参数
f3:标识参数
f4:死函数
17.4 一般性问题
g1:一个源文件中存在多种语言
g2:明显的行为未被实现
g3:不正确的边界行为
g4:忽视安全
g5:重复
g6:在错误的抽象层级上的代码
g7:基类依赖于派生类
g8:信息过多
g9:死代码
g10:垂直分隔
g11:前后不一致
g12:混淆视听
g13:人为耦合
g14:特性依恋
g15:选择算子函数
g16:晦涩的意图
g17:位置错误的权责
g18:不恰当的静态方法
g19:使用解释性变量
g20:函数名称应该表达其行为
g21:理解算法
g22:把逻辑依赖改为物理依赖
g23:用多态替代if/else 或swtich/case
g24:遵循标准约定
g25:用命名常量替代魔术数
g26:准确
g27:结构甚于约定
g28:封装条件
g29:避免否定性条件
g30:函数只该做一件事
g31:掩饰时序耦合
g32:别随意
g33:封装边界条件
g34:函数应该只在一个抽象层级上
g35:在较高层级放置可配置数据
g36:避免传递浏览
17.5 java
j1:通过使用通配符避免过长的导入清单
j2:不要继承常量
j3:常量 vs 枚举
17.6 名称
n1:采用描述性名称
n2:名称应与抽象层级相符
n3:尽可能使用标准命名法
n4:无歧义的名称
n5:为较大作用范围选用较长名称
n6:避免编码
n7:名称应该说明副作用
17.7
t1: 测试不足
t2:使用覆盖率工具
t3:别略过小测试
t4:被忽略的测试就是对不确定事物的疑问
t5:测试边界条件
t6:全面测试相近的缺陷
t7:测试失败的模式有启发性
t8:测试覆盖率的模式有启发性
t9:测试应该快速