原则
写代码时注意,写好代码后,优化优化优化、重构重构重构
稍后等于永不(Later equals never)
命名
- 名副其实
- 避免误导
- 做有意义的区分
- 使用读的出来的名称
- 使用可搜索的名称
- 避免使用编码
- 避免思维映射
- 类名和对象名应该是名词或名词短语
- 方法名应该是动词或动词短语
- 每个概念对应一个词
- 不用双关语
- 使用解决方案领域名称
- 使用源自所涉及问题领域的名称
- 添加有意义的语境,不要添加没用的语境
函数
- 短小(20行封顶)
- 只做一件事情
- 每个函数一个抽象层级(自顶向下)
- 使用描述性名称
- 函数参数三个一下
- 尽量避免使用输出参数
- 使用异常替代返回错误码
- 抽离try/catch代码块形成函数
- 消除重复
如何写出好的函数
先将代码写完,在打磨代码,分解函数,修改名称,消除重复
注释
别给糟糕的代码加注释
- 注释不能美化糟糕的代码
- 用代码诠释
- 唯一的好注释是想办法不去写注释
- 允许的注释:法律信息、提供信息的注释、对意图的解释、阐释、警示、TODO注释、放大重要性、公共API中的javadoc
- 坏的注释:喃喃自语、多余的注释、误导性注释、循规式注释、日志式注释、废话注释、注释掉的代码、HTML注释、系统级的信息、信息过多、不明显的联系、函数头、非公共代码中的javadoc
- 能用函数或变量时就别用注释
格式
- 短文件比长文件易于理解(一般200-500行)
- 源文件最顶部应该给出高层级的概念和算法
- 每组代码表示一个完整的思路,思路之间使用空白行分割
- 紧密相关的代码应该相互靠近
- 变量申明应尽可能靠近其使用位置
- 实体变量应该在类的顶部申明(被该类的大多数方法使用)
- 相关函数,调用的方法放在被调用方法的上面
- 代码行字数不超过120字
对象和数据结构
- 对象暴露行为,隐藏数据
- 数据抽象(使用接口)、使用赋值器
- 数据传送对象(DTO):只有公共变量、没有函数的类
错误处理
- 使用异常而非返回码
- 先写try-catch-finally语句
- 使用不可控异常(unchecked exception)
- 给出异常发生的环境说明
- 依调用者需要定义异常类
- 别返回null值,改为抛出异常或返回特例对象
- 别传递null值,改为检测到null值,异常抛出
类
类应该从一组变量列表开始,先写公共静态常量,然后是私有静态变量,以及私有实体变量,很少会有公共变量。公共函数应在变量列表之后。
- 类应该短小
- 单一权值原则
- 内聚(类中只有少量的实体变量,类中的每个办法都操作一个或多个这种变量,若类中每个变量都被每个方法使用,则内聚性最大)
- 保持内聚性就会得到许多短小的类(把大类拆成许多短小的类)
- 修改代码时,通过扩展系统而非修改现有代码来添加新特性,添加新特性时尽量减少对原有代码的修改
系统
- 将系统的构造和使用分开(方法:1、将全部构造过程搬迁到main中,2、使用工厂,3、依赖注入)
迭进(通过迭进设计达到整洁设计)
- 运行所有测试
- 重构
- 不可重复
- 提高表达力
- 保持类和函数短小的前提下,尽可能减少类和方法
并发编程
- 并发防御原则(单一权责原则、限制数据作用域、避免共享数据,可使用数据副本、线程尽可能独立、)
- 保持同步区域微小
- 测试线程代码(编写可插拔的线程代码、编写可调整的线程代码、运行多于处理器数量的线程、在不同平台上运行、装置试错代码,多测异常情况、自动化)
逐步改进
我们每个人都有责任把模块改进得比发现时更整洁
Junit
重构