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

工作日记是笔者记录在日常工作中对负责的前端项目和任务的总结和提炼，在工作中寻乐趣，在代码中找灵魂，输出工作中有价值有意思的沉淀，分享知识，娱乐自己。wx:wxid_wdjyyo939vja22

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

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

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

下面是具体的做法：

引入eslint

npm i eslint -S

# package.json加入
"scripts": {
    "lint:write": "eslint --debug src/* --fix"
}

.eslintrc.js eslint的配置文件，拆分如下：

module.exports = { 
   env: {}, 
   extends: {}, 
   plugins: {}, 
   parser: {}, 
   parserOptions: {}, 
   rules: {},
}

env：表示指定想启用的环境
extends：指定额外配置的选项，如 ['airbnb'] 表示使用 Airbnb 的 * linting 规则
plugins：设置规则插件
parser：默认情况下 ESLint 使用 espree 进行解析
parserOptions：如果将默认解析器更改，需要制定 parserOptions
rules：定义拓展并通过插件添加的所有规则

eslint支持多种格式的配置文件，还可以采用.yaml,.json,.yml的格式，优先级如下：

.eslintrc.js
.eslintrc.yaml
.eslintrc.yml
.eslintrc.json
.eslintrc
package.json

规则：

{
    "rules": {
        "semi": ["error", "always"],
        "quote": ["error", "double"]
    }
}

上面semi，quote是规则名称，数组的第一项是指检验级别：

off/0：关闭规则
warn/1：以 warning 形式打开规则
error/2：以 error 形式打开规则

默认配置：

"extends": "eslint:recommended"

这是默认的规则集合，也可以选择其他集合，比如：["airbnb", "google"]

husky

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

"husky": {
    "hooks": {
      "pre-commit": "npm run lint:write"
    }
  },

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

lint-staged

可是eslint会检查src下的全部文件，在一个本来就没有统一风格的项目中，几乎所有文件都有检查不通过的可能，这不是搞死自己吗。兄台，不必担忧，我有妙计。提交代码版本时只对工作区内的文件做检验，改了哪些文件就检验哪些文件，这样就大大减少了检查文件和更改量，随着时间的推移，项目的迭代，相信代码风格统一的目标达成指日可待。

lint-staged就是为了解决这个问题而诞生的，结合husky使用：

"husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
},
"lint-staged": {
    "*.(js|jsx|vue)": [
      "npm run lint:write",
      "git add"
    ]
},

目前引入eslint后，代码看这舒服了，香！