《代码的整洁之道》这本书非常好,具有很好的指导意义。如果从来没有写过代码,或者写的代码比较少,那么看这本书,会比较茫然,不知所云。如果有非常丰富的写代码经验,再来看这本书,就会发现,是如此的浅显易懂。总结下来,就是代码的整洁之道之独孤九剑。时不时的翻看一下要领,总会有意想不到的效果。
一、不整洁的代码,阅读体验是这样的:
- 乱(组织乱,职责乱,名称乱)
- 逻辑不清晰(if-else 太多)
- 绕弯子(简单的事情复杂化,复杂的事情无解化)
- 看不懂(只有写的人知道什么意思)
- 难修改(耦合严重,各种交叉)
二、整洁的代码,阅读体验是这样的:
- 清晰(是什么,做了什么,一眼看得出来)
- 简单(职责少,代码少,逻辑少)
- 干净(没有多余的逻辑)
- 好拓展(依赖的比较少,修改不会影响很多)
三、灵魂法则
- 稍后等于永不
- 破窗原理:窗户破损了的建筑让人觉得似乎无人照管。于是别人也再不关心。他们放任窗户继续破损。
- 最终自己 也参加破坏活动,在外墙上涂鸦,任垃圾堆积。一扇破损的窗户开辟了大厦走向倾颠的道路。
四、建立意识
- 代码质量与其整洁度成正比,干净的代码,既在质量上可靠,也为后期维护、升级奠定了良好基础。
- 编写代码的难度,取决于周边代码的阅读难度,想要快速实现需求,想要快速完成任务,想要轻松的写代码,先让你的书写的代码整洁易读。
- 保持整洁的习惯,发现脏代码就要及时纠正。花时间保持代码整洁,这不但有关效率,还有关效率的生存。
- 程序员遵从不了解混乱风险的项目经理的意愿,都是不专业的做法。
- 让代码比你来时更干净,如果每次提交时,都比原先更干净,代码就不会腐坏。
- 赶上期限的唯一方法,做得更快的唯一方法,就是始终尽可能的保持代码的整洁。
五、有意义的命名
- 设置可读性高的名称
- 有意义的区分
- 读的出来的名称
- 使用可搜索的名称
- 避免思维映射,不要让读者在脑中将你的名称译为他们熟知的名称
- 类名,不应该是动词
- 方法名,应当是动词或动词短语,取名应该言简意赅,别装可爱
- 每个概念对应一个词
- 别用双关语
- 使用解决方案领域名称
- 不要添加没用的语境
六、函数
- 短小,控制在20行左右,不要超过50行,缩进层级不该大于两层
- 只做一件事,单一职责。要判断函数是否做了不止一件事,就看它里面的代码,是否能再拆出一个函数
每个函数一个抽象层级, - switch语句,使用工厂模式发挥多态作用
- 使用描述性名称,长而具有描述性的名称比短而令人费解的好
- 函数的参数,超过3个参数的函数,就需要特别说明。定义的函数的参数越多,你耗费函数使用者的青春就越多,使用者需要花时间搞清楚每个参数的具体含义和顺序。最理想的参数数量是 1~2 。从测试的角度看,参数越多,可能出现的用例就越多,就越容易出错 。
- 不要有副作用,副作用就是做了名称以外的工作,不要违反只做一件事的原则
- 分割指令与询问
- 使用异常替代返回错误码
- 抽离try/catch代码块,使用错误处理代码从主路径代码中分离出来得到简化
- 错误处理就是一件事,关键try应该是这个函数的第一个单词且catch/finally后无其它内容
- 依赖磁铁,消灭错误码枚举类改用异常派生类
- 别重复自己,消除重复代码,适时封装成方法
七、被差评的注释
- 令人费解的注释,读懂花费的时间比看代码的时间还长
- 误导性注释,老旧的注释。代码才是真相,注释有可能是谎言,还是要”少写注释!
- 日志型注释。比如记录修改日志
- 废话注释。变量名、函数名已经很清晰,就不需要注释,注释里不要放一些奇怪的东西
- 注释掉的代码。没用的代码及时删除
八、注释
- 别给糟糕的代码写注释,重构!
- 提供信息的注释
- 对意图的解释
- 阐释
- 警示
- TODO 注释