一、整洁的代码
- 整洁的代码从不隐藏设计者的意图,充满了干净利落的抽象和直截了当的控制语句。
- 读写的花费时间比例超过10:1。写新代码的时候,我们一直在阅读旧代码
二、命名
- 关键在于良好的描述技巧和共有的文化背景!
- 名副其实
- 避免误导,不要使用非常相似的命名,不要使用小写l和大写O(容易和数字01搞混)
- 做有意义的区分(用数字区分通常没有意义),例如,copy(source,destination) > copy(a1, a2)。data,info等等词通常毫无意义
- 名词要便于搜索,长名 > 短名
- 类名应该是名词短语,方法名应该是动词短语
- 别抖机灵,一点也不幽默
- 每个概念对应一个词,一以贯之,不要总变来变去。fetch, retrieve, get表达的都是一个含义
- 避免双关
三、函数
- 短小!更短小!函数的缩进层级应该<=2
- 只做一件事,如果多余一件事,就进行拆分
- 函数内的语句要在同一个抽象层级上(自顶向下的coding,自顶向下的reading)
- 使用描述性的名称,别害怕名字长
- 函数的参数要尽量少,0个最好,1个也行,2个次之,3个及以上是灾难(不好记顺序,没法测)。一定要尽可能的抽象出类
- 不要传布尔参数,一定可以拆出两个函数来
- 可以把参数名放到函数名中来,比如assertEqual(expected, actual) -> assertExpectedEqualsActual(expected, actual)
- 区分开「指令型」和「询问型」的函数,不要一个函数两种事情都做
- try-catch单独封装
四、注释
- 「别给糟糕的代码加注释,重新写吧」 —— Brian Kernighan and P.J. Plaugher
- 注释的恰当用法是弥补我们再用代码表达意图是遭遇的失败
- 注释存在的时间越久,就离其所描述的代码越远。原因在于程序员不能坚持维护注释
- 好注释包括:法律信息,提供信息,对意图的解释(不是实现,是为什么这么实现),对其他人的警示,todo(一定要写好todo的功能,以及由谁负责,何时完成),强调作用
- 坏注释包括:喃喃自语,多余的注释,注释掉的代码(未来其他人不敢删除),信息过多(没人会看的),署名(源代码控制系统可以记录作者)
五、格式
- 垂直方向:紧密关联的代码应该互相靠近(调用者应该和被调用者相邻,并且调用者在上,被调用者在下(符合人从上而下的阅读习惯)),关系密切的概念也应该互相靠近
六、对象和数据结构
- 应该尽量避免曝露数据细节,应该以抽象的形态表述数据
- 过程式代码(使用数据结构的代码)方便在不改动数据结构的情况下增加函数,面向对象的代码方便在不改动现有函数的情况下增加新类
- 一切都是对象只是一个传说
- 模块不应该了解它所操作的对象的内部情形。类C的方法f只应该调用(C的方法,f创建的对象的方法,f的参数的方法,C的实体变量所持有的方法)。一连串的调用应该做切分。
- 最精炼的数据结构,是一个只有公共变量、没有函数的类(Java)
七、错误处理
- 错误处理很重要,但如果它搞乱了代码逻辑,就是错误的做法
- 抛出异常的时候,应该提供足够的环境说明,以便判断错误的来源。应该创建信息充分的错误信息,和异常一起传递出去
- 定义异常类的时候,首要考虑它们应该如何被捕获
- 别返回null,应该抛出异常,或者返回特例对象
- 尽可能避免传递null值
九、单元测试
- TDD三定律:
(1)在编写不能通过的单元测试之前,不可编写生产代码
(2)只可编写刚好无法通过的单元测试,不能编译也算是不通过
(3)只可编写刚好通过当前失败测试的生产代码 - 测试代码和生产代码一样重要,应该保持整洁
- 有了单元测试就不用再担心对代码的修改。是单元测试的代码让代码可扩展、可维护、可复用
- 整洁的测试的要素:可读性!可读性的标准:明确、简洁、足够的表达力
- 构造-操作-检验:构造测试数据,操作测试数据,检查操作是否得到预期结果
- 每个测试函数只测试一个概念
- FIRST规则:fast(测试代码运行速度应该足够快),independent(测试之间互相独立),repeatable(测试与测试环境无关),self-validating(测试输出应该是布尔值),timely(先写单元测试代码,后写生产代码)
十、类
- 类中内容的顺序:变量,函数。变量顺序:公共静态变量,私有静态变量,私有实体变量。
- 类应该短小,如果一个类无法精准命名,通常都意味着太长了。系统应该由许多短小的类,而不是少量巨大的类组成。
- 单一权责原则(SRP):类或者模块应该有且仅有一条加以修改的理由。
- 内聚:类应该只有少量实体变量,类中的每个方法都应该操作一个或者多个这种变量。
十一、系统
- 软件系统应将启动过程和运行过程的逻辑分开。
- 分解main:将构造与使用分开的方法之一,是将全部构造过程搬迁到main中。
十三、并发
- 对象是过程的抽象,线程是调度的抽象
- 并发是一种解耦策略,它将what(目的)与when(时机)分解开
- 并发有时能够改进性能,但是只在多个线程/处理器之间能分享大量等待时间的时候管用
- 并发算法的设计可能和单线程系统的设计极不相同
- 并发会在性能和编写额外代码上增加一些开销
- 正确的并发是复杂的,即便对于简单的问题也是如此
- 并发缺陷并非总能复现
- 并发常常需要对设计策略进行根本性修改
- 数据封装:严格限制对可能被共享的数据的访问
- 生产者消费者模型、读者作者模型、哲学家进餐模型
- 不要同时追踪非线程缺陷和线程缺陷,确保代码在线程之外可工作
- 在不同环境中,多线程代码的行为可能不同,尽量在所有可能部署的环境中测试。
十四、其他
- 先写可工作的脏代码,再在单元测试的辅助之下,清理它
- clover工具可以检查单元测试代码的覆盖率
- 应该限制类、模块中暴露的接口数量,类中的方法越少越好。
- 条件判断中的条件应加以封装,用来清晰的表明该条件的内容
- 用命名常量代替魔术数
- 时序耦合应该暴露出来。如果语句a必须在语句b的后面执行,那语句b的结果应该作为语句a的输入参数
- 封装边界条件,应该把所有涉及到边界条件的代码放到一起
- 避免传递浏览。每个模块只应该了解它的协作者,而非整个系统
- 测试边界条件
- 错误倾向于扎堆出现。如果某个函数出现错误,最好全面测试它