前言:
以下来自拜读《代码整洁之道》之后的总结。
代码就像沼泽,在你编程前要先滩过一大片沼泽地,到达目的地之后,才有机会编写属于你的代码。为此,我们要明白一个道理:在编程时,我们是作者更是读者。为此,我们在编程时就要时刻保持谦虚的态度优化自己的代码,就像童子军军规:“让营地比你来时更干净”。
好的代码该是怎样的呢?优雅而高效,让人赏心悦目;简单直接、干净利落、直截了当,丝毫不拖泥带水。
又该怎么做呢?
- 能通过所有测试。
- 没有重复代码。
- 体现系统中的全部设计理念。
- 尽量少的实体(如类、方法、函数等)。
下面分别是对编程的命名、函数方法、注释、格式、对相遇数据结构、错误处理、单元测试系统进行分析总结:
一、命名
1、包括:
项目名、模块名、文件名、类名、方法名、变量名等。
2、注意事项:
避免误导、做有意义的区分、能够阅读、方便搜索、避免思维映射、禁止双关、禁止多词一意、注意语境使用。
三、函数
如何写好函数?
1、精简短小
2、要求只做一件事(要么修改某对象的状态,要么返回某对象的相关信息)
3、一个函数一个抽象层级
4、使用多态
5、使用描述性的名称
6、函数参数语义明确
7、不做无意义额副词
四、注释
注释是一种必须的恶。
注释的最高境界:唯一真正好的注释是你想办法不去写的注释。
实践总结:
1、在实际中,即使再简单的一个属性或者方法都要添加注释;
2、因为是英文,水平不一致,所以阅读能力会差别很多,在命名的时候多数还可能使用的中式英语;
3、所以单纯看一个方法或属性,有不同的解读是必然的,为避免出现如此情况,那么就只有添加注释。
1、好注释:
1.1、法律信息
1.2、提供信息的注释
1.3、对意图的解释
1.4、阐释
1.5、警示
1.5、TODO注释
1.6、放大。
2、坏注释:
2.1、语义不明确
2.2、信息过多
2.3、误导性注释
2.4、循规式注释
2.5、日志式注释
2.6、废话注释
2.7、归属于署名
2.8、标记位置不合理
2.9、注释掉的代码
2.10、HTML注释
五、格式
代码格式关乎沟通的便利,而沟通是开发者的头等大事。
1、垂直格式
1.1、垂直方向的区隔与靠近
1.2、垂直距离:变量声明/局部变量、实体变量/全局变量、相关函数、概念相关
2、横向格式
2.1、水平方向的区隔与靠近
2.2、水平对齐
2.3、缩进
2.4、空范围
六、对象与数据结构
1、数据结构:以抽象形态表述数据为佳。
2、过程式代码(使用数据结构的代码):便于在不改动即有数据结构的前提下添加新函数。(难以添加新数据结构,因为必须修改所有函数)
3、面向对象代码:便于在不改动即有函数的前提下添加新类。(难以添加新函数,因为必须修改所有类)
4、得墨特尔律:模块不应了解它所操作对象的内部情形。
5、数据传送对象(DTO):只有一个公共变量、没有函数的类,为最精炼的数据结构。
七、错误处理
错误处理很重要,但不能因之搞乱了代码逻辑。
常用处理方式:
1、使用异常而非返回码。
2、使用 Try-Catch-Finally 语句。
3、适当使用不可控异常。
4、给出异常发生的环境说明。
5、依调用者需要定义异常类。
6、定义常规流程。
7、别返回null值/别传递null值。
八、单元测试
单元测试的5条规则【F.I.R.S.T法则】:
1、快速(Fast):快速运行。
2、独立(Indepeatable):相互独立。
3、可重复(Repeatable):可在任何环境中重复通过。
4、自足验证(Self-Validating):要有布尔值输出。
5、及时(Timely):测试代码在生产通过之前编写。
九、类
原则:短小、单一、内聚(如果一个类中的每个变量都被每个变量所使用,则该类具有最大的内聚性)。
十、系统
将系统的构造与使用分开:模块编程(面向对象编程OOP)、切面编程(面向切面编程AOP)。
预防缺陷:测试在前、开发在后。
总结: 通过以上各个方面的分析,从头梳理,会更加明白代码编程的 【四大设计规则】 :
1、通过所有测试。
2、消除重复代码。
3、保证表达力。
4、尽可能减少类和方法的数量。
注:
- TDD:测试驱动开发
- SRP:单一职责原则
- DIP:依赖倒转原则。细节应当依赖于抽象,抽象不应当依赖于细节。要针对接口编程,不要针对实现编程。意思就是应当使用接口和抽象类而不是具体类进行变量的类型声明、参数的类型声明、方法的返回类型声明以及数据类型的转换等。