软件开发实践-如何编写整洁的代码
2017-09-12 21:14
513 查看
最近在工作中, 经常会维护一些已经存在的代码,经常Review别人的代码,也经常请别人Review代码.
感觉Review代码真是一个很累人的工作.感谢那些为我们Review代码的同事.
很多时候,感觉Review的效果并不好,难以深入下去.
如何Review好代码,当前还没有太好的思路,结对编程是一个方法,但是自己没有实践过,仅仅在思考的层面上,所以也难以有发言权.
但是,如何方便别人Review,如何提高自己的代码质量,倒是总结了一些内容,本我大打算主要站在C/C++开发人员的角度写一下自己的总结.
有本书叫<代码整洁之道>, 主要就是讲述怎么写整洁代码的.一直以来,感觉自己写代码还算是整洁,但是看了这本书后,还是很有收获.
别人的东西毕竟是别人的,自己理解的不一定到位,在这里我把自己理解的整洁的代码整理一下.想到哪儿写到哪儿,条目未必都在一个层次上,有点乱,也不全,以后会持续整理:
l 能放在源文件中的不要放在头文件中
因为头文件的可见范围比源文件大,可能被别处使用.
能被别处使用的代码,以后就不敢轻易修改, 会使代码越来越僵化.
看代码时, 增加阅读代码负担, 会关心是否被其他地方使用.追溯代码时,扩大追溯范围.
头文件中信息太多, 会使头文件更复杂.
l 能用static的,一定要用static
在源文件中,static的函数或者变量,我们可以随便改,因为这些变量或函数的范围只在不会超出文件.但是非static的,要改动时就要小心了. 阅读代码时,也会考虑它为什么不是static的,会不会被其他地方调用.
l 在类中,能用private的不用protected,能用protected的,不用public.
不这样做,在使用 写makefile时, 可能需要include一大堆不相干的文件夹.甚至可能出现类型冲突.
l 常量,枚举如果可能,最好和结构体分离,特别是与具体业务联系密切的结构体, 最好对结构体也划分好层级
如果用于ioctl之类的头文件,最好不要出现函数
l 能不include的头文件不要引用
l 如果是库, 对外接口能写成C接口的,尽量写成C接口,而不是C++接口.
变量未经过抽象,描述性差.
变量暴露了细节. 例如有些类型可以是模块私有的,如果暴露变量,则该类型可能需要设置为外部可见的
l 变量一定要初始化
l 尽量以只读常量代替宏
长函数有很多的不方便:
1难以阅读
2 不知道逻辑段长短
有些逻辑段特别长
3 if/else一大堆
4 有些变量声明的地方距离使用的位置比较远
特别是C代码
5 缩进太多
逻辑不明显
代码列数增长
6 没有对代码进行抽象
所有代码都是细节
描述性差
7 未分层,分函数
函数名具有描述性
8 拆分大函数是重构,模式灵感的重要来源之一
重新抽象的过程
9 长的函数难以写单元测试
可能违反单一职责原则,一个函数干多件事
没有好的分层,无法方便的mock
无法分多个层测试
让代码具有自描述性.这要求我们在代码的自描述性上下功夫.例如名称,格式等.
l 有些注释要加
例如假设,限制条件,依赖或调用顺序,不说别人不知道的知识.
调用顺序尽量让代码做到不顺序调用无法使用(例如<代码整洁之道>中的’ 把逻辑依赖改为物理依赖’),但是有时候也不得不使用注释来解决,但是这不是好的方法.
使用时才声明
l 有种参数叫引用参数&
很多地方可以使用引用参数或const type&代替指针参数
l 不需要类时,不要刻意用类
毕竟增加复杂度
l 能用泛型时尽量用泛型
泛型能解决很多不用泛型无法进行的抽象.
使用泛型不会有太大的代价.
编译速度可能会变慢
l C++新标准中, function对象和Lamda表达式是很好用的东西,尽量用好
有种范式是函数式编程,使用好function对象和
99f7
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
感觉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对象和
99f7
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
相关文章推荐
- 软件开发实践-如何编写整洁的代码
- 代码那些事儿---走出软件作坊:三五个人十来条枪 如何成为开发正规军(二十八)
- 使用 JET 在 Eclipse 中创建更多更好的代码,如何掌握专家的最佳实践并提高您的模型驱动开发进度
- SharePoint2010企业开发最佳实践(一)----在 SharePoint Server 中编写有效代码
- 微软软件项目开发方法--如何编写优秀的程序( 主讲:林斌 )视频笔记
- [最佳实践]在Scrum敏捷软件开发模式中,我们是如何开Sprint 计划会议的
- 软件开发文档如何编写
- iOS应用开发最佳实践:编写高质量的Objective-C代码
- 请求大家批评修改本文--论如何才能提高软件的开发效率及写代码效率
- 论如何才能提高软件的开发效率及写代码效率
- iOS应用开发最佳实践:编写高质量的Objective-C代码
- iOS应用开发最佳实践:编写高质量的Objective-C代码
- 如何才能提高软件的开发效率及写代码效率
- 如何将算法翻译成代码,软件设计实践,一个B Plus Tree算法实现(未完待续)
- iOS应用开发最佳实践系列一:编写高质量的Objective-C代码
- 代码那些事儿---走出软件作坊:三五个人十来条枪 如何成为开发正规军(二十八) 推荐
- 如何才能提高软件的开发效率及写代码效率
- 读后感:代码那些事儿---走出软件作坊:三五个人十来条枪 如何成为开发正规军(二十八)
- Android开发之如何编写高效的Android代码?
- 代码那些事儿---走出软件作坊:三五个人十来条枪 如何成为开发正规军(二十八)