这里分享代码 review 中发现的六则糟糕代码的案例，并进行分析：

案例一

变量、属性和函数名应该使用小驼峰式命名法，并且名称是可描述的。 应该避免使用单字符变量和不通用的缩写。

某前端同学的 angular 代码：

该同学定义了一个变量叫 cg，不符合变量名可描述的规则，除了本人之外团队其他成员看不懂其含义。goToPage 和 goPage 容易混淆，语义也不明确。

案例二

尽量使用 es6 语法简化代码逻辑

某后端同学的 js 代码：

写了20多行，其实就是一句话能搞定的事情，基本功太差：

案例三

使用 作为多行注释。包含描述、指定所有参数和返回值的类型和值。

使用 作为单行注释。在评论对象上面另起一行使用单行注释。在注释前插入空行。

某前端同学的 angular 代码：

上面的注释既不规范，也是多余的，当起了一个好的名字之后，代码就已经非常明确了。案例四

逻辑互斥的 if 语句一定要配合 else 或 return 使用，把概率高的写在前面。

某后端同学的 js 代码：

上面每个判断都要执行一次，完全没有必要，这种情况下要么使用 switch 要么 if 配合 else 或 return 使用。

案例五

保持函数简短，一个好的函数适合展现在一个幻灯片（slide)上，这样如果在一个比较大房间中，也便于最后一排的人阅读。每一个函数的代码应该限制在 15 行左右，另外为了避免 if 语句过度嵌套， 应该提前将函数值返回。

某前端同学为了去除 params 对象中的 value 为 null， ，undefined 的 key 写的代码：

这种函数可维护性极差，自己写的过个星期也读不懂什么意思了，出现错误很难定位。下面是改造后的：

明显清晰很多，可读性很强，逻辑也很健壮。如果你觉得一个 15 行以内的函数搞不定某个事情，就把它拆分成多个小于 15 行的函数。

案例六

配置要写在配置文件里面统一管理，常量也要定义在单独的文件里面，常量名全部大写。

某后端同学写的 js 代码：

密钥这种配置信息写在代码里面，既不方便测试，又不利于拓展