1. 注释
不恰当的信息 注释只应该描述有关代码和设计的技术性信息。
废弃的注释 过时、无关、不正确的注释
冗余注释 注释描述的是某种充分自我表述了得东西。
糟糕的注释 值得编写的注释，也值得好好写
注释掉的代码 没人知道他存在的意义。忽视掉的代码就删掉。 版本控制器会记住他的。
2. 环境
需要多步才能实现的构建 构建系统应该是单步的小操作。
需要多步才能做到的测试 应当能够发出单个指令就可以运行全部单元测试。
3. 函数
过多的参数 函数的参数量应该少。
输出参数 输出参数违反直觉
标识函数 布尔值参数大声宣告函数做了不止一件事。它令人迷惑，应该消灭掉
死函数 永不被调用的方法应该丢弃
4. 一般性问题
一个源文件中存在多种语言
源文件中包括且只包括一种语言。当非要使用时，应尽量减少额外语言的数量和范围。
明显的行为未被实现
遵循”最小惊异原则”，*函数或类应该实现其他程序员有理由期待的行为。
不正确的边界行为
代码应该有正确行为。别依赖直觉，追索各种边界条件，并编写测试。
忽视安全
关闭失败测试，告诉自己过后再处理很不明智
重复
模板方式模式和策略模式很好的消除重复。应尽可能找到并消除重复
在错误的抽象层级上的代码
创建分离较高层级一般性概念与较低层级细节概念的抽象模型，很重要。
所有较低层级概念放在派生类中，所有较高层级概念放在基类中。
基类依赖于派生类
将概念分解到基类和派生类的最普遍的原因是较高层级基类可以不依赖于较低层级派生类概念
信息过多
设计良好的模块有着非常小的接口，让你事半功倍，反之就事倍功半了
学会限制类或模块中暴露的接口数量。类中的方法越少越好。函数知道的变量越少越好。类拥有的实体变量越少越好。尽量保持接口紧凑，通过限制信息来控制耦合度。
隐藏你的数据，工具函数，常量和临时变量。不要创建大量方法，或大量实体变量的类
死代码
即不执行的代码。不会发生的if语句体中。不会发生的catch中
垂直隔离
变量和函数应该在靠近被使用的地方定义
前后不一致
命名前后一致，坚决贯彻，就能让代码更易于阅读和理解
混淆视听
去掉没有使用的信息。保持源文件整洁，良好地组织，不被搞乱。
特性依恋
类的方法只应对其所属类中的变量和函数感兴趣，不该垂青其他类中的变量和函数。
人为耦合
不相互依赖的东西不该耦合。人为耦合是指两个没有直接目的的之间模块的耦合。
选择算子参数
函数调用结尾遇到一个false参数
代码要尽可能具有表达力
位置错误的权责
在哪里放代码?
需要静态函数时，确保没机会打算让他有多态行为
使用解释性变量
将计算过程打散成在用有意义的单词命名的变量中放置的中间值。
函数名称应该表达其行为
理解算法
获得这种知识和理解的最好途径，往往是重构函数，得到某种整洁而足具表达力、清楚呈示如何工作的东西
把逻辑依赖改为物理依赖
依赖者模块不应对被依赖着模块有假定（逻辑依赖），他应当明确询问后者全部信息。
用多态代替if/eles 或Switch/Case
团队成员都应遵循这些约定，
用命名常量替代魔术数
魔术数 泛指任何不能自我描述的符号
准确
坚守结构甚于约定的设计决策。
封装条件
避免否定性条件
否定式要比肯定式难明白一些。尽可能将条件表示为肯定形式
函数只该做一件事
让时序耦合变得可见
别随意
构建代码需要理由，而且理由应于代码结构相契合
边界条件难以追踪，把边界条件的代码集中到一处，不要散落于代码中。
函数应该只在一个抽象层级上
在较高层级放置可配置数据
避免传递浏览
确保模块只了解其协作者，不了解整个系统的浏览图。让直接协助者提供所需的全部服务。
5. Java
通过使用通配符避免过长的导入清单
不要使用继承常量
常量Vs枚举 多使用枚举
6. 名称
采用描述性名称
名称应与抽象层级相符
尽可能使用标准命名法
无歧义的名称
为较大作用范围选用较长名称 名称的长度应于作用范围的广泛度相关
避免编码 不应在名称中包含类型或作用范围信息
名称应该说明副作用 名称应该说明函数、变量或类的一切信息
7. 测试
测试不足
使用覆盖率工具
别略过小测试
被忽略的测试就是对不确定事物的疑问
测试边界条件
全面测试相近的缺陷
测试失败的模式有启发性
测试覆盖率的模式有启发性
测试应该快速