一次代码review引发的思考与总结（好的编码习惯总结）

缘由

毕业后工作一年多，一直想总结一下工作中收获到的一些好的经验，但是一直没有找到机会把这些零散的经验好好的总结汇总起来。这一次在公司经历了整个一个功能模块从无到有的过程，包括，需求分析，模块设计，代码编写，前后端联调与自测，以及后期的bug的查找与修改，且整个过程都是由我一人负责，感觉又收获到了很多宝贵的经验。借着这个机会就将收获的经验总结记下。

编码

在公司完成了一个模块的代码编写后，进行了一场劈头盖脸的code review。为什么说是劈头盖脸呢，因为以我一年多的工作经验编写出来的代码，在公司编码多年的老鸟看来，虽然功能都能够实现，但是各个地方都有需要提高的地方，提出了很多细节上应该注意的东西。

命名

命名在我看来，是最重要的问题，同时也是一大难题，好的命名可以让变量或者函数甚至文件的功能作用一目了然。正所谓好的命名就是注释。
**命名风格：**常见的命名风格有驼峰式命名，下划线命名，匈牙利命名。这些命名风格各有各的优缺点。但是在我看来，在函数和变量的命名上只要风格统一，能够清晰的说明其作用即可。
**函数命名：**函数命名使用动宾结构可直观的说明函数的作用，如下所示

//例如：获取学生列表数据
int get_students_list()
//例如：修改学生列表数据
int update_students_list(char* data)

**变量命名：**变量命名需尽量表明变量类型和用途，就算某些语言在定义变量时就已经说明变量的类型，但是还是应该对某些关键变量的类型在命名上进行表示

//xxx模块的配置
xxxConf := get_xxx_cfg()

//xxx的计数器
xxxCnt := 0

日志

日志的打印一定要遵循一下几个原则：

1.报错日志需详细：为了方便排查问题，error级别日志尽量打印出详细信息，例如原因，参数值，变量名等。

2.涉密和敏感信息不可打印：类似于密码之类的敏感信息不得出现在日志中，这属于安全编码要注意的地方，如实在需要打印该类日志，需要对信息进行脱敏。

3.关键路径日志打印需谨慎：关键路径打印日志一定要谨慎，执行率高的关键路径随意打印日志可能会将磁盘打满。

4.数据操作必须打印日志：例如写入和删除操作，为了避免操作人抵赖和欺骗行为，在这类非幂等的接口和操作中，必须打印出详细日志。

风格

if语句
if语句遵循最短路径原则，方便代码阅读。

//以下方式为错误方式
if (xxxx) {
	xxxx;
	xxxx;
	xxxx;
} 
else {
	xxxx;
}

//最短路径写法：将短的执行逻辑放在前
if (xxxx) {
	xxxx;
} 
else {
	xxxx;
	xxxx;
	xxxx;
}

for循环
for循环注意其中的函数调用，当一些公共的函数调用在循环中会用到时，需将其提出到循环外层。

//错误方式
for(int i = 0; i < 3; i++) {
	int conf = get_xxx_conf();
	int xxx = conf->{xxx};
}

//将公共的函数调用放在外侧，避免不必要的开销，造成性能问题
int conf = get_xxx_conf();
for(int i = 0; i < 3; i++) {
	int xxx = conf->{xxx};
}

常量
一些特殊的常量值最好定义为C语言中宏定义的形式，或者在文件头进行const定义，避免在代码中出现过多的数值，否则会让后期代码维护变得很难，一时想不起当初这个值的意义。

//特殊常量定义
const (
	XXXX_INIT   	   = 0
	XXXX_FAILED        = -1
	XXXX_SUCCESS       = 1
)

注释

代码注释不在于多，在于精，好的命名风格和恰当的注释可以增强代码的可读性，让后面维护的人看了赏心悦目，看一眼就知道其逻辑和功能。
文件注释
在新建一个文件时，在文件头加上文件注释，表面其文件所在的模块，包含了哪些功能实现，文件添加的时间，作者。

// 内容：xxxx模块所有接口
// 日期：xxxx:xx:xx
// 作者：xxx

函数注释
函数注释和文件注释类似，需要表面最基本的函数功能，参数，返回值。

//功能：获取xxxx配置信息
//参数：path: 类型[string]，配置路径
//返回值：ret：类型[conf] 具体配置
//作者：xxx
//添加时间：xxxx:xx:xx
conf get_xxx_conf(string path){
	xxxxx;
	return ret;
}