代码不规范,同事两行泪

start

eslint是规范团队书写一致风格代码的利器,有了它你也很难写出乱七八糟的代码(至少在风格上),因此,许多团队会将eslint至于git commit 之前,先检测一遍是否符合规范再commit,这里我们就开始接着我们chapter-02的代码来配置一个简单的ESlint的规范。

step

全局安装eslint

npm i eslint -g

init ESlint规则

我们使用全局安装的ESlint来“傻瓜式”地设置我们的ESlint规则,我们只要在命令行中输入:eslint --init,选择自己喜欢的配置,并且自动下载一些需要的依赖:

image

这个时候,eslint会自动在当前文件夹中添加一个.eslintrc.js

1
2
3
module.exports = {
"extends": "airbnb"
};

这是eslint自动为我们设置的eslint规则,extends表示规则继承standard,也就是使用standard这一套规则,那么他有哪些规则呢,我们可以到这里查看其详细的配置airbnb,或者说我们直接找到nodemodules中的eslint-config-airbnb查看其规则,当然这里我们可以到当然这不是固定的,我们能够进行一些自定义修改。

分析代码

简单配置完成后,我们可以使用npm script的方式来查看我们代码中有哪些不规范之处,这时,我们需要在package.json中的script加上:

1
2
3
"scripts": {
"lint": "eslint src/*.js"
}

当我们运行 npm run lint 后,会打印出我们代码中不规范之处。

image

我们可以选择手动修改,但是eslint能够自动修改这些不规范的代码,只需要在scripts上加上 –fix:

1
2
3
"scripts": {
"lint": "eslint --fix src/*.js"
}

这样无论再不规范的饿代码,lint之后也能有模有样。

整合到git

当团队合作时,我们可能会忘记lint之后再commit,这个时候可能就会影响到小伙伴们阅读代码,这个时候我们就能一个工具来杜绝这种现象:pre-commit,他会在git commit之前先跑某个脚本,如果没过的话就不允许commit,所以很适合跟lint做搭配。

  • 下载pre-commit: npm i pre-commit -D
  • 配置package.json:
1
2
3
4
"scripts": { 
"lint": "eslint --fix src/*.js"
},
"pre-commit": ["lint"],

我们做一个测试,在index.js中写入以下不规范代码:

1
2
3
4
5
6
7
8
9
require('./index.css');

console.log('122214444111111xi333323xix444222i');
let a = 999;
console.log("222");
if (module.hot) {
// 实现热更新
module.hot.accept();
}

这个时候我们尝试去提交代码,则会出现以下提示:

image

我们返回到index.js中,发现一些缩近的单双引符号已经被lint了,但是像console和定义变量,这个是不会被lint的,所以只能我们手动将其删除或者注释。

1
2
3
4
5
6
7
8
9
10
// 被lint后的代码
require('./index.css');

console.log('122214444111111xi333323xix444222i');
const a = 999;
console.log('222');
if (module.hot) {
// 实现热更新
module.hot.accept();
}

我们手动注释掉eslint无法处理的问题:

1
2
3
4
5
6
7
8
9
10
// 被lint后的代码
require('./index.css');

//console.log('122214444111111xi333323xix444222i');
//const a = 999;
//console.log('222');
if (module.hot) {
// 实现热更新
module.hot.accept();
}

这个时候,我们便可以提交啦~

VSCode插件智能提示

vscode能够在我们build之前就能根据你设置的eslintrc中的规则来给你实时提醒,我们只需要在vscode中下载插件:ESlint,重启编辑器就能看到vscode的提示:

image

不仅如此,当你保存文件的时候,还能帮助你自动更正不符合规范的格式。

自定义规则

写死的规范固然不好,我们团队中肯定有些自定义的规范,比如需要写分号,或者允许出现console语句,这时,我们就需要配置.eslint文件:

1
2
3
4
5
6
7
8
module.exports = {
"extends": "airbnb",
"rules": {
"quotes": ["error", "single"],
"semi": ["error", "never"],
"no-console": ["off"]
}
};

这里我们添加了一个rules字段,表示一些我们自定义配置,quotes表示我们使用''还是""去括住字符,这里的single表示单引号,而前面的error表示如果不用单引号则直接报错,我们也可以将error改为warning,表示不报错只警告,下面的smi表示是否在语句末加上;,no-console表示是否可以出现console语句,这里我们选择了off,即表示关闭no-console这个规则。更详细的配置可以查阅官方文档:eslint中文

last

这个章节我们使用了eslint和pre-commit来规范了我们的代码风格,能够很大程度上的提高编码规范,我们总结以下eslint的作用:
1. 帮你找出语法错误

没定义变量就拿来用、少了括号等等常见的语法错误

  1. 确保你遵循最佳实践

不使用全局变量、建议使用=== 而非 ==

  1. 提醒你删掉多余的程式码

有些变量定义了却没有使用、import了没有使用的模块、空的class constructor …

  1. 统一基本的coding style

要不要加分号、使用单引号或双引号、缩排使用space 或tab 等等

本章节的代码已经上传到Github,传送门webpack-study,请自行切换到chapter-03分支。