注:大家好,我是restrain(一个才疏学浅的开发人员)。我在学习这本书的过程是,刚开始学习时每一章都会记录一篇笔记,但后面学习到味道与启发章节后发现我在日常编码中需要注意的地方以及我学习这本书的最初目的都在这一章节中了,故而删掉了之前记的所有笔记。将所得精炼到这篇笔记中。
核心:在读完本书后学到的写出好代码的一些方法。
1.注释
1.1 什么是糟糕的注释
- 被注释掉的代码。例:我们在开发中经常会看到被注释了好几年的代码。
- 过时的注释。例:我们在维护代码的同时要么删掉要么同步维护现有的注释,而不是只维护代码。目的是避免误导。
1.2 如何写出好的注释
- 首先尽量不要使用注释,通过代码把你要做的事情讲清楚。
- 不可避免使用注释的情况下,要保证注释的明确、简单。
- 不要注释代码,git的作用就是记录历史代码。
2.命名
2.1 如何给出好的命名
- 方法命名多数要用动词
- 如果需要一个很长很长的单词才能表明你定义这个函数或者方法的目的,其实问题也不大,虽然会损失一些美观,但是讲清楚你要做什么更重要
3.无用分支代码
我在刚开始从事开发工作时,写代码的时候就很害怕,总觉得会出各种各样的问题,脑袋里总是会蹦出各种各样的场景,这直接导致了我在梳理开发文档的时候就很痛苦,编码的过程也感觉自己写了很多大概率没有啥用的代码。
后面随着工作经验的提升,思路也发生了一些变化。其实只要保证主链路没问题就已经完成了90%的工作量了,剩下的其实就是健壮性的考虑。如果纠结于是否需要给某种出现可能性不大甚至不可能出现的场景去做处理时,我们可以把思路转换为我是否能够接受出现这个场景的后果。
4.函数
4.1 抽取
我在面对一个很长很长的方法时,我一般会把他要做的事情切分为一个一个步骤,然后将这些步骤抽出来作为方法,用方法名表示我这一步要做什么事情,然后按照顺序调用。
原因:我们看代码也是自顶向下看的,所以我们如果让层级比较高的函数中只有我们完成这个功能的步骤,而将实现细节都抽取到层级较低的函数中,当功能出现问题时,专注于其中一个步骤即可。而且这样做读者也更容易理解我们写代码时的思路。
4.2 一致的代码层级
我目前对于层级的理解就是,你既然要抽取了,你就抽取彻底,不要让细节代码和你抽取出来的方法同时存在于一个高层级方法中。
5.让坏味道变成好味道
5.1 魔法值
使用常量和枚举来替代魔法值。
5.2 条件取反
这个严格上不能算是坏味道,但会导致不明确,影响代码可读性。
条件取反不如肯定条件来的直观,当然条件取反很多情况下也是不可避免的。
对于复杂条件尝试条件封装,因为复杂条件需要代码阅读者去分析上下文才能知道if语句中的复杂条件是为了判断什么。如果我们把复杂条件封装为一个函数通过函数名的方式告诉读者这个条件是什么,这对于代码阅读者来说无疑是友好的。
