读书笔记《代码整洁之道》味道与启发上-一一网

本章算是一个糟糕代码清单。列出了所有作者觉得不够整洁的点。本章可以作为代码review的标准来看。

主要从以下七个方面来阐述 1.注释 2.环境 3.函数 4.一般性问题 5.java 6.名称 7.测试。作为前端开发者跳过第五个还有六个方面。

注释

不恰当的信息：

作者，最后的修改时间等版本管理工具能记录的。（这点我不是很同意，因为仓库会被迁移，所以版本管理工具也不一定可靠，而且不能保证commit的时候提交的信息都是有意义的，我觉得加个注释也无妨）

废弃的注释：

过时的，不正确的注释就是废弃的注释。也就是说如果注释内容已经和代码不符了就要立刻删除或者更新掉

冗余的注释：

如果注释描述的东西看代码就能一目了然那么这段注释就是冗余的，比如说 i++ 就没必要再写一句注释 //i加1了。或者 let a = 0 也没必要写个注释说初始化a为0

糟糕的注释：

语法错误或者有错别字的注释说很多废话的注释都是糟糕的注释。如果要写注释就好好写。

注释掉的代码：

有一部分代码被注释起来是为了防止后续会再用到，但实际上很少有注释代码重新派上用场的时候时候，他们的存在反而会分散开发者的注意力。

2.环境

需要多步才能实现的构建：

构建系统应该是单步的小操作，应该能用单个命令签出系统，并用单个指令去构建它。

需要多步才能做到的测试：

对于项目的全系统测试也应该通过单个指令就能触发。

函数

参数过多：

函数的参数应该越少越好，没有最好，一个次之，如果超过三个就需要重新考虑，避免这种情况，

输出参数：

输出参数指的是函数想对某个参数作出修改后再把这个改后的参数作为输出。这样是违反直觉的。如果我们有这样的需求，我们可以直接改变它所在的对象的状态，比如说定义函数 appendFooter (report)
本意是对report 对象加个footer 那么我们最好这么写，report.appendFooter();

标识参数：

标识参数指的是参数里有个布尔值，有布尔值参数说明了函数做了不止一件事，值为true时做一件事，值为false的时候干另一件事。我们应该把这种函数拆解成了两个小函数

死函数：

死函数指的是永远不被调用的方法，他们应该被删除。版本管理工具会记住这些代码。

一般性问题

一个源文件中存在多种语言：理想中源文件只包含一种语言，现实中，我们可能会多于一种语言，但是应该尽力减少源文件中额外语言的数量和范围。（我感觉这个对于前端开发来讲有点不太现实，特别是vue来说，他的html,css 和js本来就是杂糅的，从这个角度看可能react也更符合作者的意思）

明显的行为未被实现：

函数名字取好后，别人看到这个函数名可能会对这个函数的功能有一定的推论，比如说一个add（）的函数，别人看到了就会觉得这个是用来计算加法的，但是如果作者没有实现这个功能而使用来去做字符串拼接。那这个就代表明显的行为未被实现。

不正确的边界行为：

开发者可能对自己的代码比较有自信，觉得自己的代码没啥问题，但是每种边界条件，极端情形，每种异常应该都要考虑到。应该追索每种边界条件，并编写测试。

忽视安全：

这条主要是用来警告开发者不要去忽略编辑器控制台等提示的警告和错误提醒。对于前端开发者来说就是不要在本地关掉eslint的警告。

重复：

遇到重复的代码说明抽象没有做到位。这些重复的代码可以当作子程序，或者另一个类。
有一些较隐蔽的重复是在不同的模块中重复出现的检测同一组条件的switch/case 或者if/else 链。
更隐蔽的形态是算法类似，但是代码不太一样的重复。这种可以通过模版方法模式，或者策略模式来修正。有很多设计模式都是为了消除重复而产生的，我们要重视对重复的消除。

在错误的抽象层级上的代码：

创造一般性概念的高层级抽象模型和细节概念的低层级抽象模型很重要。java里创建抽象类来容纳高层级的概念模型，创建派生类来容纳低层级的概念模型。具体来说就是和细节有关的常量，变量或者工具函数在派生类中。基类（抽象类）对这些东西一无所知。

（同样对于前端来说，公共组件里面应该要提供一些抽象概念，但是不要添加一些细节性的东西。 vue提供了vue.extend（）方法也可以实现组件的继承。但是我们更为常用的方法是先创建一个公共组件，然后把它当作子组件，在外面调用它。虽然这样子和父的叫法有点和java是相反的，令人迷惑，但是意思大概都是这个意思。）

这段逻辑是说不要在基类上写细节的东西。同理也不要在公共组件里写一些细节性的东西。这样才能更好的解耦。