整理凌乱代码的有效姿势【工作日记02】
下文可能存在图片未显示问题,可异步到 原文 阅读
维护项目是几乎每个程序员日常中比不可少了的工作,接手项目又是维护的项目来源中,令人“可恨”的一种方式,因为看代码无非有三个感觉:“这代码666”,“这代码好像是我写的”,“这垃圾代码简直就像shi一样”。在不幸,入职接手的项目给我的就是第三感觉。
项目之前经过几个人手,在没有引入eslint等代码规范管理情况下,代码风格凌乱不堪,不像是一个团队写的。可能有人会说,搞这些花里胡哨的,代码不是照样能用。大师说人生最大的智慧是不要跟傻逼争论,嗯你说的对。
- 代码风格统一,可读性改善,有利于团队协作
- 有利于代码交付
- 重要的是对心情好
下面是具体的做法:
- 引入eslint
1
2
3
4
5
6npm i eslint -S
# package.json加入
"scripts": {
"lint:write": "eslint --debug src/* --fix"
} - .eslintrc.js
eslint的配置文件,拆分如下:1
2
3
4
5
6
7
8module.exports = {
env: {},
extends: {},
plugins: {},
parser: {},
parserOptions: {},
rules: {},
}
- env:表示指定想启用的环境
- extends:指定额外配置的选项,如 [‘airbnb’] 表示使用 Airbnb 的 * linting 规则
- plugins:设置规则插件
- parser:默认情况下 ESLint 使用 espree 进行解析
- parserOptions:如果将默认解析器更改,需要制定 parserOptions
- rules:定义拓展并通过插件添加的所有规则
eslint支持多种格式的配置文件,还可以采用.yaml,.json,.yml的格式,优先级如下:1
2
3
4
5
6.eslintrc.js
.eslintrc.yaml
.eslintrc.yml
.eslintrc.json
.eslintrc
package.json
规则:1
2
3
4
5
6{
"rules": {
"semi": ["error", "always"],
"quote": ["error", "double"]
}
}
上面semi,quote是规则名称,数组的第一项是指检验级别:
- off/0:关闭规则
- warn/1:以 warning 形式打开规则
- error/2:以 error 形式打开规则
默认配置:1
"extends": "eslint:recommended"
这是默认的规则集合,也可以选择其他集合,比如:[“airbnb”, “google”]
- husky
一般我们会在提交版本时候做检验,而不是每次保存的时候,因为那样频繁的检查会造成开发效率低下,这正是husky库解决的问题。可以把它当成实现git钩子的js库。在package.json下添加:1
2
3
4
5"husky": {
"hooks": {
"pre-commit": "npm run lint:write"
}
},
其他的git钩子还有pre-push,commit-msg等
- lint-staged
可是eslint会检查src下的全部文件,在一个本来就没有统一风格的项目中,几乎所有文件都有检查不通过的可能,这不是搞死自己吗。兄台,不必担忧,我有妙计。提交代码版本时只对工作区内的文件做检验,改了哪些文件就检验哪些文件,这样就大大减少了检查文件和更改量,随着时间的推移,项目的迭代,相信代码风格统一的目标达成指日可待。
lint-staged就是为了解决这个问题而诞生的,结合husky使用:1
2
3
4
5
6
7
8
9
10
11"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.(js|jsx|vue)": [
"npm run lint:write",
"git add"
]
},
目前引入eslint后,代码看这舒服了,香!