软件开发实践:如何编写整洁的代码

Posted 2020-10-06 荣-

最近在工作中, 经常会维护一些已经存在的代码,经常Review别人的代码,也经常请别人Review代码.

感觉Review代码真是一个很累人的工作.感谢那些为我们Review代码的同事.

很多时候,感觉Review的效果并不好,难以深入下去.

如何Review好代码,当前还没有太好的思路,结对编程是一个方法,但是自己没有实践过,仅仅在思考的层面上,所以也难以有发言权.

但是,如何方便别人Review,如何提高自己的代码质量,倒是总结了一些内容,本我大打算主要站在C/C++开发人员的角度写一下自己的总结.

有本书叫<代码整洁之道>, 主要就是讲述怎么写整洁代码的.一直以来,感觉自己写代码还算是整洁,但是看了这本书后,还是很有收获.

别人的东西毕竟是别人的,自己理解的不一定到位,在这里我把自己理解的整洁的代码整理一下.想到哪儿写到哪儿,条目未必都在一个层次上,有点乱,也不全,以后会持续整理:

1控制可见范围

我觉得代码中,控制可见范围最重要.

l  能放在源文件中的不要放在头文件中

因为头文件的可见范围比源文件大,可能被别处使用.

能被别处使用的代码，以后就不敢轻易修改, 会使代码越来越僵化.

看代码时, 增加阅读代码负担, 会关心是否被其他地方使用.追溯代码时，扩大追溯范围.

头文件中信息太多, 会使头文件更复杂.

l  能用static的，一定要用static

在源文件中,static的函数或者变量,我们可以随便改,因为这些变量或函数的范围只在不会超出文件.但是非static的,要改动时就要小心了. 阅读代码时,也会考虑它为什么不是static的,会不会被其他地方调用.

l  在类中,能用private的不用protected,能用protected的,不用public.

2 头文件

l  抽象层次不同的代码不要放在一起，特别是头文件

不这样做，在使用 写makefile时， 可能需要include一大堆不相干的文件夹.甚至可能出现类型冲突.

l  常量，枚举如果可能，最好和结构体分离，特别是与具体业务联系密切的结构体， 最好对结构体也划分好层级

如果用于ioctl之类的头文件，最好不要出现函数

l  能不include的头文件不要引用

l  如果是库， 对外接口能写成C接口的，尽量写成C接口，而不是C++接口.

3 变量

l  不要对外暴露变量，而是接口

变量未经过抽象，描述性差.

变量暴露了细节. 例如有些类型可以是模块私有的，如果暴露变量，则该类型可能需要设置为外部可见的

l  变量一定要初始化

l  尽量以只读常量代替宏

4 函数

l  不要有长函数

长函数有很多的不方便:

1难以阅读

2 不知道逻辑段长短

有些逻辑段特别长

3 if/else一大堆

4 有些变量声明的地方距离使用的位置比较远

特别是C代码

5 缩进太多

逻辑不明显

代码列数增长

6 没有对代码进行抽象

所有代码都是细节

描述性差

7 未分层，分函数

函数名具有描述性

8 拆分大函数是重构，模式灵感的重要来源之一

重新抽象的过程

9 长的函数难以写单元测试

可能违反单一职责原则,一个函数干多件事

没有好的分层,无法方便的mock

无法分多个层测试

5注释

l  尽量不添加多余的注释

让代码具有自描述性.这要求我们在代码的自描述性上下功夫.例如名称,格式等.

l  有些注释要加

例如假设,限制条件,依赖或调用顺序,不说别人不知道的知识.

调用顺序尽量让代码做到不顺序调用无法使用(例如<代码整洁之道>中的’ 把逻辑依赖改为物理依赖’),但是有时候也不得不使用注释来解决,但是这不是好的方法.

6 不要将C++当C使用

l  局部变量不需要再最前面声明

使用时才声明

l  有种参数叫引用参数&

很多地方可以使用引用参数或const type&代替指针参数

l  不需要类时，不要刻意用类

毕竟增加复杂度

l  能用泛型时尽量用泛型

泛型能解决很多不用泛型无法进行的抽象.

使用泛型不会有太大的代价.

编译速度可能会变慢

l  C++新标准中， function对象和Lamda表达式是很好用的东西，尽量用好

有种范式是函数式编程,使用好function对象和Lamda表达式是一种函数式编程的实验.

l  尽量不使用继承实现扩展

l  对外的接口最好写成C的

l  数据和操作最好在一个类中，而不是分开

这一点我是有些疑问的.

l  如果一个类中的所有成员都是static的，建议使用namespace代替类

同一命名空间， 可以放在多个文件中

使用时，可以使用using namespace 节省输入

l  使用#program once代替头文件中的宏判断和定义来保证头文件的唯一性

l  类名有描述性,不需要在成员变量中再重复类名相关的描述文字

l  使用bool类型代替BOOL

BOOL是用户自定义类型,可能存在TRUE为0的情况,bool不会存在这种情况.

如果使用BOOL,请不要将TRUE看成true,FALSE看成FALSE.不要重新定义TRUE和FALSE