浅析团队代码命名规范、如何实现团队协作代码规范：ESLint检测、Prettier格式化、VSCode编辑器自动检测设置及共享配置

一、命名规范

　　经过社区的不断发展，协定了命名包含以下几种规范：

1、下划线命名：user_name

2、中划线命名：user-name

3、小驼峰命名：userName

4、大驼峰命名：UserName

　　有了这些规范，开发者们起名字的时候心里就有谱了。而且这些规范目前也被大多数开发者们接受，如果不按照规范命名，很可能会被同事吐槽喽！当规范成为普遍共识之后，大家按照自己的喜好使用不同的规范，逐渐形成了自己的编码习惯。在一个团队中，每个开发者往往各自有各自的编码习惯。然而这又成为了问题。再拿变量举例：一个团队中，有的人习惯用下划线命名变量，如 user_name；有的人习惯用驼峰命名变量，如 userName。这两种命名方式都正确，都符合规范，但是会造成团队的代码风格混乱，无法统一。

　　那为什么要统一呢？统一的好处有很多。比如我们统一规定：命名变量用下划线，命名方法用小驼峰。那么在团队协作时，大家看到下划线就知道这是一个变量，看到小驼峰就知道这是一个方法。十个人的代码写出来是一个人的风格，不需要了解其他的编码风格，实现无障碍协作。

　　十个人的代码写出一个人的风格，说起来很理想，但是靠监督和自觉实现几乎是不可能的。怎么办呢？看下面：

二、实现代码规范的三招技巧

一、ESLint

　　团队协作开发项目，由于每个人的编码习惯不同，会写出各种各样的代码。这样的代码又乱又难以维护。所以我们希望有这样一个工具，可以制定一套比较完整全面的规范，如果大家的编码不符合规范，程序就会警告甚至报错，用这种工具来倒逼团队成员遵守统一的代码风格。

　　这个工具是有的，我们都听过，就是大名鼎鼎的 ESLint，ESLint 有两种能力：

• 检查代码质量，如是否有已定义但未使用的变量
• 检查代码风格，换行，引号，缩进等相关的规范

　　这两种能力几乎涵盖了绝大部分代码规范，并且具体规范是可配置的，团队可以定制自己喜欢的代码风格。定制规范后，项目运行或热更新时，ESLint 就会自动检查代码是否符合规范。

1、问：ESLint 检查与 TypeScript 检查有啥区别？

　　答：TypeScript 只会检查类型错误，而 ESLint 会检查风格错误。

2、ESLint 规范

　　上面说过，ESLint 可以自定义检查规范，规范定义在 .eslintrc.json 配置文件的 rules 对象下。比如，定义规范，字符串必须使用双引号

{
  "rules": {
    "quotes": ["error", "double"]
  }
}

　　定义好之后，如果你的代码中字符串使用单引号，ESLint 就会报错。quotes 表示引号规范，是众多规范中的一个，它的值是一个数组。数组第一项是错误级别，是以下 3 个值之一：

　　off 或 0，关闭规范

　　warn 或 1，警告级别规范

　　error 或 2，错误级别规范

　　数组第二项才是真正的规范，具体完整的规范参考官网：https://eslint.bootcss.com/docs/rules/，打开上面的网页，打绿钩的表示是已配置的。需要自定义直接写在 rules 里即可。

二、Prettier

　　如果你配置的编码规范比较复杂和严格，比如字符串必须单引号，代码结尾必须用分号，换行必须是 2 个 tab 且不可以用空格。像这种很细的规范，大家开发过程中难免会有不符合，这个时候控制台就会频繁报错，开发人员就会频繁修复一个空格一个标点符号，时间久了异常烦人。

　　正因为如此，在脚手架生成的项目中虽然默认都开启了 ESLint，但是很多人使用不久后觉得烦人，效率低下，所以都手动关闭了 ESLint。

　　那么，有没有更高效的方法，让大家非常快捷的写出完全符合规范的代码呢？有，它便是：Prettier，Prettier 是当前最流行的代码格式化工具，它最主要的作用就是格式化代码。

　　什么是格式化？上面我们用 ESLint 定制了编码规范，当检测到不规范的代码，提示异常，然后需要我们开发人员按照提示手动修复不规范的地方。而格式化的威力，是将不规范的代码，按照规范一键自动修复。

// 首先在项目下安装：
npm install prettier --save-dev

// 然后新建 .prettierrc.json 文件：
{
  "singleQuote": true,
  "semi": true
}
// 这个配置文件和上面 ESLint 下的 rules 配置作用一致，就是定义代码规范
// 没错，Prettier 也支持定义规范，然后根据规范格式化代码

// 列一下 Prettier 的常用规范配置：
{
  "singleQuote": true, // 是否单引号
  "semi": false, // 声明结尾使用分号(默认true)
  "printWidth": 150, // 一行的字符数，超过会换行（默认80）
  "tabWidth": 2, // 每个tab相当于多少个空格（默认2）
  "useTabs": true, // 是否使用tab进行缩进（默认false）
  "trailingComma": "all", // 多行使用拖尾逗号（默认none）
  "bracketSpacing": true, // 对象字面量的大括号间使用空格（默认true）
  "jsxBracketSameLine": false, // 多行JSX中的>放置在最后一行的结尾，而不是另起一行（默认false）
  "arrowParens": "avoid" // 只有一个参数的箭头函数的参数是否带圆括号（默认avoid）
}

// 批量格式化通过模糊匹配查找文件，比较常用，建议定义在 script 脚本中，如下：
// package.json
"scripts": {
  "format": "prettier --write \"src/**/*.js\" \"src/**/*.ts\"",
}
// Prettier 还支持针对不同后缀的文件设置不同的代码规范，如下：
{
  "semi": false,
  "overrides": [
    {
      "files": "*.test.js",
      "options": {
        "semi": true
      }
    },
    {
      "files": ["*.json"],
      "options": {
        "parser": "json-stringify"
      }
    }
  ]
}

　　问：ESLint 与 Prettier 有啥区别？

　　相同点：都可以定义一套代码规范。

　　不同点：ESLint 会在检查时对不规范的代码提示错误；而 Prettier 会直接按照规范格式化代码。

　　所以，ESLint 和 Prettier 定义的规范要一致，不能冲突。

三、VSCode

　　上面，我们通过 ESLint 和 Prettier 两招神技，实现了代码规范制定，代码规范检查，以及根据规范一个命令格式化代码，使得统一团队代码风格变的非常容易。

　　然而，突破效率的挑战是没有极限的。这时候又有小伙伴发声了：虽然是容易了，但是检查代码还是得依赖检查命令，格式化代码也得依赖格式化命令，这样总显得不够优雅。

　　好吧，不够优雅，那还有优雅的解决方案吗？答案是有。它就是我们的 VSCode

 1、强大的插件

　　VSCode 除了轻量启动速度快，最强大的是其丰富多样的插件，能满足不用使用者各种各样的需求。

　　在众多插件中，ESLint 就是非常强大的一个。没错，这个插件就是我们前面说到的 ESLint 在 VSCode 上支持的同名插件。

　　安装了这个插件之后，之前需要在终端执行 eslint 命令才能检查出来的异常，现在直接标记在你的代码上了！即使是你敲错了一个符号，该插件也会实时的追踪到你错误的地方，然后给出标记和异常提醒。这简直大大提升了开发效率，再也不用执行命令来检查代码了。

　　既然编辑器有 ESLint 插件，那是不是也有 Prettier 插件呢？猜对了，当然有插件，插件全名叫 Prettier - Code formatter，在 VSCode 中搜索安装即可。

　　Prettier 插件安装之后会作为编辑器的一个格式化程序。在代码中右键格式化，就可以选择 Prettier 来格式化当前代码。

　　如果要想 Prettier 实现自动化，则还需要在编辑器中配置

2、编辑器配置

// VSCode 中有一个用户设置 setting.json 文件，其中保存了用户对编辑器的自定义配置。这个配置非常丰富，详见官网
// 首先我们在这个配置当中将 Prettier 设置为默认格式化程序：
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}
// 设置好这一步之后，重点来了！ 我们再来配置保存文件自动格式化：
{
  "editor.formatOnSave": true
}

　　配好之后，神奇的事情发生了：当你写完代码保存的时候，发现你正在编辑的文件立刻被格式化了。也就是说，无论你的代码按不按照规范写，保存的时候自动帮你格式化成规范的代码。

　　这一步其实是保存文件的时候自动执行了格式化命令。因为我们上面配置了默认格式化程序为 Prettier，现在又配了保存时格式化，相当于将文件保存和 prettier 命令连接了起来。

　　到这一步，我们已经实现了代码的自动检查与自动格式化，现在你编码的时候不需要考虑什么格式规范的问题，只要正常保存，编辑器会自动帮你做好这些事情。

 3、共享编辑器配置

　　上面我们在编辑器经过一顿配置，终于实现了自动格式化。现在我们要把这些设置同步给团队内的其他成员，该怎么办，难道要一个一个再配一遍？不用这么麻烦。VSCode 的设置分为两类：

• 用户设置：应用于整个编辑器
• 工作区设置：应用于当前目录/工作区

　　这两类的配置内容是一模一样的，区别只是优先级的问题。如果你打开的项目目录包含工作区设置，那么这个工作区设置会覆盖掉当前的用户设置。

　　所以要想将设置同步给团队内的其他成员，我们不需要去改动用户设置，只需要在项目目录下新建一个工作区设置即可。

　　添加工作区设置方法：在项目根目录下新建 .vscode/setting.json 文件，在这里写需要统一的编辑器配置。所以我们把上面的 Prettier 配置写在这里即可实现共享。