整理凌乱代码的有效姿势【工作日记02】

我是图片

下文可能存在图片未显示问题,可异步到 原文 阅读

维护项目是几乎每个程序员日常中比不可少了的工作,接手项目又是维护的项目来源中,令人“可恨”的一种方式,因为看代码无非有三个感觉:“这代码666”,“这代码好像是我写的”,“这垃圾代码简直就像shi一样”。在不幸,入职接手的项目给我的就是第三感觉。



项目之前经过几个人手,在没有引入eslint等代码规范管理情况下,代码风格凌乱不堪,不像是一个团队写的。可能有人会说,搞这些花里胡哨的,代码不是照样能用。大师说人生最大的智慧是不要跟傻逼争论,嗯你说的对。



  • 代码风格统一,可读性改善,有利于团队协作
  • 有利于代码交付
  • 重要的是对心情好

下面是具体的做法:

  1. 引入eslint
    1
    2
    3
    4
    5
    6
    npm i eslint -S

    # package.json加入
    "scripts": {
    "lint:write": "eslint --debug src/* --fix"
    }
  2. .eslintrc.js
    eslint的配置文件,拆分如下:
    1
    2
    3
    4
    5
    6
    7
    8
    module.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”]

  1. husky

一般我们会在提交版本时候做检验,而不是每次保存的时候,因为那样频繁的检查会造成开发效率低下,这正是husky库解决的问题。可以把它当成实现git钩子的js库。在package.json下添加:

1
2
3
4
5
"husky": {
"hooks": {
"pre-commit": "npm run lint:write"
}
},

其他的git钩子还有pre-push,commit-msg等

  1. 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后,代码看这舒服了,香!