代码风格Eslint和EditorConfig

1 Eslint

1.1 简介

ESLint 是一个开源的 JavaScript 代码检查工具，由 Nicholas C. Zakas 于 2013 年 6 月创建。代码检查是一种静态的分析，常用于寻找有问题的模式或者代码，并且不依赖于具体的编码风格。对大多数编程语言来说都会有代码检查，一般来说编译程序会内置检查工具。

JavaScript 是一个动态的弱类型语言，在开发中比较容易出错。因为没有编译程序，为了寻找 JavaScript 代码错误通常需要在执行过程中不断调试。像 ESLint 这样的可以让程序员在编码的过程中发现问题而不是在执行的过程中。

ESLint 的初衷是为了让程序员可以创建自己的检测规则。ESLint 的所有规则都被设计成可插入的。ESLint 的默认规则与其他的插件并没有什么区别，规则本身和测试可以依赖于同样的模式。为了便于人们使用，ESLint 内置了一些规则，当然，你可以在使用过程中自定义规则。

ESLint 使用 Node.js 编写，这样既可以有一个快速的运行环境的同时也便于安装。

1.2 编码规范

每个程序员都有自己的编码习惯，有的人写代码一行代码结尾必须加分号;，有的人觉得不加分号 ; 更好看。有的人写代码一行代码不会超过 80 个字符，认为这样看起来简洁明了，有的人喜欢把所有逻辑都写在一行代码上，觉得别人看不懂的代码很牛逼。有的人使用变量必然会先定义 var a = 10;，而粗心的人写变量可能没有定义过就直接使用 b = 10。

1.3 使用 Eslint

确保你的电脑安装了 node 和 npm 环境

1. 创建项目：
   npm init
2. 本地安装eslint：
   npm i eslint --save-dev
3. 设置 package.json 文件

"scripts": {
    "lint": "eslint ./src",
    "lint:create": "eslint --init"
 }

4. 生成 .eslintrc.js 文件。提供编码规则
   npm run lint:create
5. 校验代码的程序，自动检验 src 目录下所有的 .js 文件
   npm run lint

"lint": "eslint ./src --fix", 加上 --fix 参数，是 Eslint 提供的自动修复基础错误的功能。--fix 只能修复基础的不影响代码逻辑的错误，像 no-unused-vars 这种错误只能手动修改

跳过 lint 校验

const apple = "apple"; // eslint-disable-line
const balana = "balana"; // eslint-disable-line
 
/* eslint-disable */
alert('foo');
/* eslint-enable */

1.4 .eslintrc.js 解析

module.exports = {
 "env": {
 "browser": true,
 "commonjs": true,
 "es6": true 
 },
 "extends": "eslint:recommended",
 "parserOptions": {
 "ecmaVersion": 2016,
 "sourceType": "module"
 },
 "rules": {
 "indent": [
 "error",
 "tab"
 ],
 "linebreak-style": [
 "error",
 "windows"
 ],
 "quotes": [
 "error",
 "double"
 ],
 "semi": [
 "error",
 "always"
 ]
 } };

该文件导出一个对象，对象可以包含属性 env、extends、parserOptions、plugins、rules、globals

• env、parserOptions、plugin 、parse标识我们程序将要使用到的语法（交互式的指令 对我们来说不重要）
• Parse 代表使用的解析器
• extends
"extends": "eslint:recommended",值为 “eslint:recommended” 的 extends 属性启用一系列核心规则，这些规则是经过前人验证的最佳实践（所谓最佳实践，就是大家伙都觉得应该遵循的编码规范），想知道最佳实践具体有哪些编码规范，可以在 eslint 规则表 中查看被标记为 √ 的规则项，eslint-config-recommended 本质上是一个包
• rules
  用于覆盖继承来的规则，我们可以通过设置 rules 来定义我们自己的编码规范。
  ESLint 附带有大量的规则，修改规则应遵循如下要求
  “off” 或 0 - 关闭规则
  “warn” 或 1 - 开启规则，使用警告级别的错误：warn (不会导致程序退出)
  “error” 或 2 - 开启规则，使用错误级别的错误：error (当被触发的时候，程序会退出)

1.5 常用规则

如果对编码规范具体某一条规则不了解的话，可以在 查看用法：eslint 规则表 https://cn.eslint.org/docs/rules/

• object-shorthand：设置该规则，表示对象属性要简写。

var foo = {x: x}; // 会报错
var bar = {a: function () {}}; // 会报错
var foo = {x}; // 不会报错
var bar = {a () {}}; // 不会报错

• prefer-arrow-callback：要求回调函数使用箭头函数
• no-trailing-spaces：禁止行尾空格
• no-shadow：禁止变量声明与外层作用域的变量同名

function sum (num) {
 var num = 2; 
// 报错，因为 num 变量作为参数已经申明过了
}

1.6 ESlint与 Git 结合

到目前为止,我们只是单独的在 Eslint 的体系中使用编码约束。没有什么强有力的手段来进行强制约束。我们可以在 Git 中结合 Eslint。让代码在没有通过 Eslint 的情况下禁止提交。

• 哈士奇 husky 文档
  npm install husky -D

Edit package.json > prepare script and run it once:
npm set-script prepare "husky install"
npm run prepare
Add a hook:

npx husky add .husky/pre-commit "npm test"
git add .husky/pre-commit

1.7 eslintignore

. eslintignore

2 EditorConfig

2.1 概述

在团队开发中，统一的代码格式是必要的。但是不同开发人员使用的编辑工具可能不同，这样就造成代码的不统一。

目前为止，还是有很多人陷入在 tabs vs spaces 之类的争论中。不是每个人都在严格要求自己的代码规范和风格，对于多人协作的项目这容易出现问题。毕竟每个人所用的 IDE 和编辑器都可能不同。

EditorConfig 帮助开发人员定义和维护不同编辑器之间一致的编码风格。EditorConfig 项目由定义编码样式的文件格式和一组文本编辑器插件组成，这些插件使编辑器能够读取文件格式并坚持已定义的样式。编辑器配置文件易于阅读，并且可以很好地与版本控制系统一起工作你只需配置一个 .editorconfig 文件，在其中设置好要遵守的代码规范，放在项目的根目录下，就能够在几乎所有的主流 IDE 和编辑器中复用了，可以将 .editorconfig 文件也提交到版本控制系统中，就不需要针对不同 IDE 和编辑器再单独进行设置了。

2.2 配置文件

EditorConfig 插件会自动在项目中寻找名为 .editorconfig 的配置文件，每个文件的样式偏好会自动根据该文件所在文件夹的 .editorconfig 文
件向上寻找所有同名文件，直到某个配置的文件种包含了 root=true。最接近该文件的配置文件中的设置优先最高

2.3 配置文件格式

实例

支持的参数

• root：表明是最顶层的配置文件，发现设为 true 时，才会停止查找 .editorconfig
• charset：编码类型，可以是 latin1、utf-8、utf-8-bom、utf-16be 和 utf-16le。不建议使用 utf-8-bom。
• end_of_line:换行符，lf、cr 或者 crlf。
• trim_trailing_whitespace：设为 true; 删除换行符前面的任何空白字符.
• insert_final_newline：设为 true; 以确保文件在保存时以换行结束
• indent_style： 缩进风格，可以是 tab 或者 space，对应 hard tabs 和 soft tabshard-tabs 是硬件 tab，就是按一个 tab 键，soft-tabs 是软件 tab，通过按 4 个 space 键实现。
• indent_size：缩进的宽度，即列数，必须是整数。