2020 年 06 月 05 日
缘起
最近想这阅读一本书,一本不是code工具书,又对编程有所提升的书籍,决定读一读 收藏已久的《代码 的整洁之道》 —— Robert C.Martin
看书笔记和观后感记于此 📖
军规
我们接到一个需求 |一个功能,首先 reveiew 代码可行性而不是在以前的代码上堆积
然而目前大多数公司遵循他们自以为是的 “敏捷式开发” 需求压力大 导致这一点很难落地实现,包括我自己,个人觉得这就是社区开源项目的质量普遍比公司内部项目质量高的原因之一
命名
- 避免映射思维 如 i和k 这种的变量很容易和 for 循环中的 k j i 混淆
- 有义意的命名
- 类名
类名和对象应该是名词或者名词短语如:Customer、WikiPage、Account 等避免使用 Manager、Data、Info 这样类似的类名,类名不应是动词
- 方法名
函数
以上是一个示例代码片段,一个糟糕的示例
- 重构之后
- 你大概能明白重构之前的代码,但是你应该不会了解其细节,而下面的重构后的代码我们就可以一目了然 很容易获取到其信息
-
我们不难发现良好的代码具备以下特点
-
短小,函数的第一条规则就是要短小函数每行不应该有150个字符串那么长,函数也不应该有100行那么长,20行最佳
-
代码块和缩进,诸如 if switch while 之类的语句其中的代码块只应该有一行,改行是一个函数语句的调用,函数的嵌套层级不应该多于一层或者两层
JavaScript ES5 之前在这个方面就有这样子非常糟糕写法,也被大家所诟病 充斥着大量的回调地狱、多层闭包、等
-
只做一件事,我们在写一个函数的时候要遵循
低耦合的
的特点,一个函数只做一件事,也就是 单一职责的性质 -
switch 语句,写出短小的 switch 语句很难,哪怕只有2个条件的switch 判断的代码块也要大的多,switch 天生就要做多个事,不过我们可以保证每个switch 都埋藏着较低的抽象层级 而且永不重复
-
使用描述性名称
-
函数参数,最理想的函数参数是0参数、其次是1参数、再其次是2参数、尽量避免出现3参数(多参数)的情况,如果看起来 函数确实需要多个参数我就可以考虑吧把参数封装对象|类
-
结构化编程,每个函数、函数中的每个代码块都应该只有一个入口、一个出口,意味着每个函数中只能有一个
return
语句, 循环中不能有break
continue
语句。但是对于小函数偶尔出现return、break、continue
语句没有坏处,所以我们要保持函数短小精悍
-
-
小结:
每个系统都是使用某种领域特定的语言来搭建,而这种语言是吃宵夜设计来描述那个系统的;
注释
- 用名称代替过于明了的注释
// Format matched kk:mm EEE, MM, dd, yyyy
Pattern timeMatcger = PAatern.compile(
这类注释 有时候会管用,但我们更推荐使用函数名称来传达信息 responderBeingTested
-
对于意图的解释
-
阐述解释:有些地方过于抽象 描述起来太冗长,我可以清楚的描述 参数、返回值
-
警示:用于警告他其他程序员会出现某种后果
-
TODO 注释 用计划的方式放在代码中 也有助于IDE定位
-
归属 署名 有助于找到对应的人
-
注释掉掉掉代码:这是非常糟糕的做法 尽量避免