代码规范的建立

找了一天有关前端代码规范的文章，这两篇写的最通俗易懂了。

作者：乃乎
链接：https://zhuanlan.zhihu.com/p/...
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
————————————————
版权声明：本文为CSDN博主「前端菜鸟报道」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/liule18...

我是前端程序猿！我要写 JavaScript！

好的，你写吧。有什么问题呢？没有问题，当只有你一个人的时候，什么问题都不是问题，只要你看的懂你自己的代码。可是呢，问题来了，现代社会讲究的是团队合作，你一个人是什么都写不出来的（如果你是 Linus 请忽略这句话）。

多人合作有什么问题呢？代码风格不一致。这个问题会导致什么结果呢？

git diff 的时候会导致很多仅仅是格式的修改出现。比如你喜欢用两个空格，张三喜欢用一个 tab，而 Pony 老师则喜欢用三个空格。这时候你需要对 Pony 的代码进行修改，看到他三个空格很不爽，修改了逻辑的同时，顺便帮他调整了一下格式，自认为帮了人家一个大忙，然后提了 MR。Pony 老师作为 approver 看到自己的代码被改的面目全非而感到气气，于是很愤怒的拒绝掉了你的 MR ...
每个团队有自己的标准导致新人的加入需要花很大时间熟悉代码风格。经过一个多月的 debate，Pony 老师终于累了，于是放弃争辩决定以后跟你一样使用两个空格。你获得了胜利，认为既然团队统一了风格，那不会再有风格的问题出现了。直到团队来了个新人 - Tony 老师，Tony 老师多年大厂经验让他形成了自己的一套观点，那就是 -- 四个空格才是最完美的缩进，于是你的战斗又开始了...

兄弟，你不是一个人。曾经有个自由人 A 的眼睛被另外一个自由人 B 弄瞎了，B 想赔偿 A 一个金币，A 却认为应该赔偿两个金币，于是他们发生了争吵，于是当地治安官介入。治安官怎么解决这个问题呢？"诶，这个 so easy 啊。这汉谟拉比法典上不是写的清清楚楚么，'以眼还眼，以牙还牙'”。于是 B 的眼睛也瞎了，虽然最后谁也没有得到自己想要的，但总算，问题解决了。

ESLint

这个故事告诉我们一个道理，要解决问题，就要先把规矩都列出来写在文件里，于是大名鼎鼎的 ESLint 出来了。

ESLint 是什么呢？
是一个开源的 JavaScript 的 linting 工具，使用 espree 将 JavaScript 代码解析成抽象语法树 (AST)，然后通过AST 来分析我们代码，从而给予我们两种提示：

代码质量问题：使用方式有可能有问题 (problematic patterns)
代码风格问题：风格不符合一定规则 (doesn’t adhere to certain style guidelines)

(这里的两种问题的分类很重要，下面会主要讲）

终于有一天，你发现了 ESLint 这个工具，于是你拉上 Pony 老师，Tony 老师你们一起开了个会，在你苦口婆心的劝说下，终于大家一致同意使用两个空格作为缩进，于是

你安装了 ESLint，并将下面的配置写入 .eslintrc文件。

// .eslintrc {        
    "indent": ["error", 2]    
}

你还统一让大家下载了 ESLint 的 VSCode 插件，没有通过 ESLint 校验的代码 VSCode 会给予下滑波浪线提示。
为了万无一失，你还添加一个 pre-commit 钩子 eslint --ext .js src，确保没有通过 lint 的代码不会被提交。
更让人开心的是，之前不统一的代码也能通过 eslint --fix 来修改成新的格式。

Airbnb Style Guide

你很开心，这样一来，不管有多少新人来都不会再有缩进格式的问题了。但是，你后面又发现，新来的小红竟然在使用大括号的时候新起一行。于是你陷入了沉思，觉得不可能针对每个格式都要大家开会讨论。于是你打开了 Google，发现很多公司都有跟你一样的问题。很多大公司都提出了自己公司的标准，其中有一个叫 Airbnb 的公司做的是最好的，于是你又叫了所有人来开会，终于大家一致同意使用一套完整的规范。会后，你 install 了 eslint-config-airbnb ，并且将 .eslintrc 文件改成了下面这样，终于大功告成。

// .eslintrc {
  "extends": ["airbnb"]
}

Prettier

于是问题都解决了么？那是不可能的，解决了的话这篇文章也不会这么长 - 。-

上面我们说到，ESLint 主要解决了两类问题，但其实 ESLint 主要解决的是代码质量问题。另外一类代码风格问题其实 Airbnb JavaScript Style Guide 并没有完完全全做完，因为这些问题"没那么重要"，代码质量出问题意味着程序有潜在 Bug，而风格问题充其量也只是看着不爽。

代码质量规则 (code-quality rules)
no-unused-vars
no-extra-bind
no-implicit-globals
prefer-promise-reject-errors
...
代码风格规则 (code-formatting rules)
max-len
no-mixed-spaces-and-tabs
keyword-spacing
comma-style
...

这时候就出现了 Prettier，Prettier 声称自己是一个有主见 (偏见) 的代码格式化工具 (opinionated code formatter)，Prettier 认为格式很重要，但是格式好麻烦，我来帮你们定好吧。简单来说，不需要我们再思考究竟是用 single quote，还是 double quote 这些乱起八糟的格式问题，Prettier 帮你处理。最后的结果，可能不是你完全满意，但是，绝对不会丑，况且，Prettier 还给予了一部分配置项，可以通过 .prettierrc 文件修改。

所以相当于 Prettier 接管了两个问题其中的代码格式的问题，而使用 Prettier + ESLint 就完完全全解决了两个问题。但实际上使用起来配置有些小麻烦，但也不是什么大问题。因为 Prettier 和 ESLint 一起使用的时候会有冲突，所以

首先我们需要使用 eslint-config-prettier 来关掉 (disable) 所有和 Prettier 冲突的 ESLint 的配置（这部分配置就是上面说的，格式问题的配置，所以关掉不会有问题），方法就是在 .eslintrc 里面将 prettier 设为最后一个 extends

// .eslintrc {      
    "extends": ["prettier"] // prettier 一定要是最后一个，才能确保覆盖 }

(可选，推荐) 然后再启用 eslint-plugin-prettier ，将 prettier 的 rules 以插件的形式加入到 ESLint 里面。这里插一句，为什么"可选" ？当你使用 Prettier + ESLint 的时候，其实格式问题两个都有参与，disable ESLint 之后，其实格式的问题已经全部由 prettier 接手了。那我们为什么还要这个 plugin？其实是因为我们期望报错的来源依旧是 ESLint ，使用这个，相当于把 Prettier 推荐的格式问题的配置以 ESLint rules 的方式写入，这样相当于可以统一代码问题的来源。

// .eslintrc {      
    "plugins": ["prettier"],      
    "rules": {        
        "prettier/prettier": "error"      
    }    
}

将上面两个步骤和在一起就是下面的配置，也是官方的推荐配置

// .eslintrc {
  "extends": ["plugin:prettier/recommended"]
}

（全剧终）

Ref

eslint（包括其他一些 lint 工具）的主要功能包含代码格式的校验，代码质量的校验。而 Prettier 只是代码格式的校验（并格式化代码），不会对代码质量进行校验。代码格式问题通常指的是：单行代码长度、tab长度、空格、逗号表达式等问题。而代码质量问题指的是：未使用变量、三等号、全局变量声明等问题。

Prettier是一个开箱即用流行的代码格式化工具。Prettier的配置十分克制，它认为在代码格式化方面牺牲一些灵活性，可以为开发者带来更多收益。

Lint和prettier区别

那 ESLint 和 Prettier 的区别是什么呢？eslint（包括其他一些 lint 工具）的主要功能包含代码格式的校验，代码质量的校验。而 Prettier 只是代码格式的校验（并格式化代码），不会对代码质量进行校验。代码格式问题通常指的是：单行代码长度、tab长度、空格、逗号表达式等问题。而代码质量问题指的是：未使用变量、三等号、全局变量声明等问题。

解决方案

一、背景&痛点
痛点：
在团队项目开发过程中和代码交接时，因个人编码习惯的不同往往出现代码风格不一致的情况，造成不必要的代码维护成本，有时甚至大于新功能的开发成本。
对于代码的版本管理（svn、git或者其他），代码格式不一致带来的问题是严重的，在代码一致的情况下，因为格式不同，文件被标记为 diff，导致无法检查代码和校验。
背景：
之前的 touch2.0 框架采用 eslint —fix 和编辑器自带的代码格式化工具来进行代码格式化，但存在以下缺点：

每种编辑器可能会有不一样的代码格式；
eslint 的样式规则并不太准确，会与编辑器自带的格式化工具冲突。
二、解决办法
上述问题的原因在于 eslint 做的“太多”，最理想的情况应该是让eslint专心负责代码规则校验，而调整代码风格交给prettier来完成，各司其职，互不干扰。

prettier的优势
自身优势：支持多种语言、集成多数的编辑器、可配置化、规则更加准确合理。
其他优势：能够完美的配合 eslint 使用，减轻 eslint 的工作，因为将代码样式校验交给了 prettier，所以可以将代码校验的规则更准确地应用到代码真正的规范上面。
此外，prettier在代码风格的一些细节上做得很好，在实际体验之后，才能感受到prettier的好用。

实际效果：

三、使用 prettier
这里以vsCode编辑器为例，推荐前端开发统一使用vsCode：http://eip.teamshub.com/t/347...

（一）、安装 prettier
// 使用yarn：

yarn add prettier --dev --exact

// 全局安装

yarn global add prettier

//使用npm：

npm i -D --save-exact prettier

// 全局安装

npm i --global prettier

（二）、配合 eslint 检测代码风格
前提是你的项目中已经使用了 esLint，有 eslintrc.js 配置文件，这个 touch2.0框架已经具备，不再赘述。

禁用 eslint 风格校验：
prettier 的少数代码风格与 eslint 的代码风格存在冲突，事实上，eslint 几乎与所有主流格式化工具的代码风格存在冲突，这样就会造成代码格式化之后，eslint 大量警告扑面而来。所以，首先我们要让 eslint 对代码风格“放手”，专注于代码规则。
安装插件：

npm i -D eslint-config-prettier

配置eslintrc.js：

{
  extends: ['prettier']
}

通过使用eslint-config-prettier插件，能够关闭一些不必要的或者是与 prettier 冲突的 eslint 规则。使用的时候需要注意 prettier 必须要在extends的最后一项。

使用 eslint 运行 prettier：
安装插件：

npm i -D eslint-plugin-prettier

eslint-plugin-prettier插件能调用prettier对你的代码风格进行检查，其原理是先使用prettier对你的代码进行格式化，然后与格式化之前的代码进行对比，如果过出现了不一致，这个地方就会被prettier标记。
接下来，需要在 eslintrc.js 配置文件中添加 rules，“prettier/prettier”: “error”，表示在被prettier标记的地方抛出错误信息：

// .eslintrc.js
{
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error"
  }
}

完成第二步就可以使用命令行来格式化你的代码了：
在package.json的scripts下添加如下代码，然后使用npm run format，就能监听src目录下的文件并进行格式化，可以添加多个文件列表：

"scripts": {
  "format": "onchange 'src/**/*.js' 'src/**/*.vue' -- prettier --write {{changed}}"
}

但是这种方式不太灵活，也不够方便。所以强烈推荐安装 prettier 插件 Prettier - Code formatter。

（三）、安装 prettier 插件 Prettier - Code formatter
在 VS Code 扩展中搜索Prettier - Code formatter进行安装即可：

安装插件后，调出系统设置 settings.json 并将 prettier 设置为默认格式化工具，可以为所有语言或特定语言设置此项：

{
  // 所有语言
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  // 特定语言
  "[html]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[vue]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[css]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  ···
}

这样，我们就可以使用shift+alt+f（vsCode默认快捷键）来格式化代码，可以对单个文件格式化。

还可以通过修改vsCode设置，实现保存既格式化

"editor.formatOnSave": true,

（四）、prettier 配置
prettier 的配置不是必须的，如果不配置，prettier 会按照 .editorconfig 配置文件的规则去校验，但不建议这样做。

prettier 的默认规则足够准确，但我们仍然可以配置我们想要的风格。一共有三种方式支持对 prettier 进行配置：

根目录创建 .prettierrc 文件，能够写入YML、JSON格式的配置，带有可选扩展名：（.json/.yaml/.yml无扩展名优先）；
根目录创建 .prettierrc.js 或 .prettier.config.js 文件，并对外export一个对象；
在package.json中新建prettier属性。
我在项目中使用的是根目录 .prettierrc 文件配置方式：

{
  "tabWidth": 2, // 一个tab代表几个空格数，默认2
  "useTabs": false, // 是否使用tab进行缩进，默认false
  "singleQuote": true,// 字符串是否使用单引号，默认false
  "trailingComma": "es5",// 是否使用尾逗号，可选值""，默认none
  "printWidth": 100,// 每行最大字符数，超过会换行，默认80
  "endOfLine": "auto",// 行尾换行方式，可选值""，默认auto
  "overrides": [
    {
      "files": ".prettierrc",
      "options": { "parser": "json" }
    }
  ]
}

14
以上为我的项目中使用的配置，更多配置项可参考：https://prettier.io/docs/en/o...

（五）、提交即格式化
prettier 还可以很好的集成的项目中，利用git的hooks机制，在提交commit时自动调用 pretter 进行格式化。实现这一点，还需要 Huksy、pretty-quick 这两个工具。

Husky：可以方便的让你通过npm scripts来调用各种git hooks；
pretty-quick：在更改的文件上运行Prettier。

安装husky，pretty-quick：

npm install pretty-quick husky --save-dev

在package.json中添加：

"husky": {
  "hooks": {
    "pre-commit": "pretty-quick --staged"
  }
}

这样在进行git提交的时候代码就会自动进行格式化了。

总结
上述规范目前已在项目中实践，实际体验良好，使用 eslint+prettier 的规范代码优点总结如下：

几乎不需要纠结，因为 prettier 的可配置化和非常简单的配置方法；
团队开发，不需要开发人员学习代码风格，保存既是规范；
避免不符合规范的代码提交，减少代码版本维护成本；
不需要去修复 eslint 报告的风格问题。

代码规范的建立