- 命名语意化：有意义的命名能够替代注释
- 类名和对象名应该是名词或名词短语
- 方法名应该是动词或动词短语
- 不要害怕名称过长
- 命名要避免误导
- 多使用能够读的出来的名称：避免自造词, 多使用合乎规范的英文单词
- 避免使用双关语
- 多使用大家达成统一认识的领域名称(术语)
- 避免添加无意义的语境
- 使用易搜索的名称
- 易搜索指的是在海量代码中快速定位到该命名
- 以单个字母命名的名称仅适用于短方法中的本地变量(如 js 中 d(document)，w(window))
- 命名的长短应该与作用域大小成对应关系
- 函数的第一规则是短小，20行封顶
- 每个函数只做一件事
- 函数中的语句在一个抽象层级上
- 函数的参数
- 函数参数个数：理想情况函数参数个数依次为 0、1、2，超过两个应该避免
- 当函数需要三个或者超过三个以上参数时候，推荐把一些对象封装为类
- 当我们需要传入个数可变的参数时候，可以使用参数列表
- 抽离 try/catch 代码块（一个函数只做一件事，错误处理就是一件事 ）
- DRY 原则：不要重复自己
- 尽量不写注释，能用代码表达就用代码表达
- 值得写的注释
- 法律信息
- 提供信息的注释
- 对意图的解释
- 警告
- TODO 注释
- 坏的注释
- 多余的注释：无法提供比代码本身提供更多的信息，或者说读注释并不比读代码效果好
- 误导性注释：你的注释不够精确，甚至本身就有错误
- 日志式注释：记录代码变更或者代码 log 等
- 格式的目的是保持可维护性和可扩展性
- 遵守团队规则，一个团队的代码风格要统一
- 使用异常而非返回码
- 抽离try catch包含的代码块，其中代码块抽象为一个函数
- FIRST原则
- 快速 Fast
- 独立 Independent 测试应该相互独立
- 可重复 Repeatable 测试应当在任何环境中重复通过
- 自足验证 Self-Validating 测试应该有布尔值输出
- 及时 Timely 最好的方式是 TDD
- 类的封装
- 遵守单一权责原则
- 不要重复
- 分离并发相关代码与其它代码
- 严格限制对可能被共享的数据的访问
- 避免使用一个共享对象的多个同步方法
- 保持同步区域微小，尽可能少设计临界区