命名
- 有意义的命名
- 名副其实
- 避免魔法数字
- 避免误导
- 注意拼写
- 做有意义的区分（a1,a2,a3...,aN）纯属误导
- 使用读的出来的名称，而非自造词
- 使用可搜索的名称，例如找MAX_CLASSES_PER_STUDENT很容易，找数字7就很麻烦
- 避免使用编码，制作编码系统误导读者，不必成员前缀/后缀，会无视
- 避免思维映射，不应当让读者在脑中把你的名称翻译为他们熟知的名称（不能有a,b,就取名c）（r代表url）
- 类名应该是名词或名词短语，如Customer,WikiPage,避免使用Manager,Processor,Data,类名不应当是动词
- 方法名应当是动词或动词短语，如postPayment,deletePage,save,属性访问器，修改器，和断言应该根据其值命名，加上，get,set,is前缀
- 别扮可爱，宁可明确，勿为好玩
- 每个概念对应一个词
- 别用双关语，例如把单个参数放到collection里去，不应该把这个方法叫做add,和其他add方法保持了一致，但是实际语义却不同，应该用insert,或append之类的词
- 使用解决方案领域名称，给这些事取个技术性的名称，通常是最靠谱的做法
- 使用源自所涉问题领域的名称
- 添加有意义的语境(firstName,lastName,street,....)放一起是构成了一个地址，但是如果在某个方法里看到某个变量，是很难推断出来的，可以添加前缀(addFirstName,addLastName,addStreet等)
- 不要添加没用的语境
函数
- 函数应该短小，20行封顶最佳
- 只做一件事
- 每个函数一个抽象层级
- 自顶向下读代码：向下规则
- 使用描述性名称
- 函数参数，需要少，尽量避免三个以上的参数
- 无副作用
- 使用异常替代返回错误码
- 抽离try/catch代码块
- 错误处理就是一件事
- 别重复自己
- 结构化编程
- 想什么，写什么，然后再打磨它
注释
- 注释不能美化糟糕的代码
- 用代码来阐述
- 好注释，有些注释是必须的，也是有利的，唯一真正好的注释是你想办法不去写的注释
- 阐述，把参数或返回值翻译为某种可读形式
- 警示
- TODO,是一种程序员认为应该做，但是由于某些原因目前还没做的工作
- 放大，注释可以用来放大某种看起来不合理之物的重要性
- 公共API中的javadoc
- 坏注释，坏注释都是糟糕的代码的支撑或接口
- 多余的注释
- 误导性注释
- 循规式注释，每个函数或每个变量都要有注释是全然愚蠢可笑的
- 日志式注释
- 废话注释
- 注释掉的代码，注释掉的代码堆积在一起，就像酒瓶底的渣滓一般
- html注释
- 非本地信息，请确保描述了离它最近的代码
- 信息过多
- 不明显的联系
格式
....
- 团队规则
对象和数据结构
- 数据抽象
- 数据，对象的反对称性
- 得墨x耳律，模块不应了解它所操作对象的内部情形
- 数据传输对象，最为精炼的数据结构，是一个只有公共变量，没有函数的类，这种数据结构有时被称为数据传输对象,或DTO
错误处理
- 使用异常而非返回码
- 先写Try-Catch-Finally语句
- 使用不可控异常
- 给出异常发生的环境说明
边界
- 使用三方代码
- 浏览和学习边界
- 学习性测试的好处不只是免费
- 整洁的边界
单元测试
- 保持测试整洁
- 整洁的测试
- 双重标准
- 每个测试一个断言
- 快速，独立，可重复，自足验证，及时
类
- 封装
- 类应该短小
- 单一职责原则（系统应该由许多短小的类而不是少量巨大的类组成）
- 内聚
系统
- 将系统的构造与使用分开
- 分解main
- 工厂
- 依赖注入
- 扩容
- java代理
- 测试驱动系统架构
- 优化决策
迭进
- 运行所有测试
- 重构
- 不可重复
- 表达力
- 尽可能少的类和方法
并发编程
- 为什么要并发：并发是一种解耦策略，它帮助我们把做什么（目的）和何时（时机）做分解开。
- ....
逐步改进
- 渐进
- ....
