共计 7434 个字符，预计需要花费 19 分钟才能阅读完成。
本文从代码标准，代码查看，代码格式化，以及编辑器自动化实现的方向，介绍代码标准对立在咱们团队的实际利用。
纲要预览
本文介绍的内容包含以下方面：
- 意识代码标准
- 制订和对立标准
- 神技一：ESLint
- 神技二：Prettier
- 神技三：VSCode
- 附录：命名和我的项目构造标准
意识代码标准
先来思考两个问题：
- 什么是代码标准？
- 为什么须要代码标准？
如果你是一个经验丰富的前端开发，你肯定接触过这样的老我的项目：变量名是 abc，fds 这种随便起的，或者是 name1, name2 这种带数字起名，这样的变量不加正文，鬼都不晓得它是干什么的。
这类代码就是一种典型的不标准代码。这样的代码除了让咱们开发人员情绪火暴，最重要的问题是，它极大的升高了团队合作的效率和程序品质。
在团队合作过程中，当组内其他人须要应用或 review 你的代码，看到这种状况，除了喷你，还要破费大量工夫理解你写的是什么。同时这样非常容易造成变量抵触，带来未知隐患，调试艰难等问题，甚至能够看出一个程序员的编码态度和业余水平。
当然，代码标准蕴含很多方面，变量命名标准只是最根底的标准。不标准的中央越多，程序品质越低，团队合作的效率也就会越低。
理解了不标准的代码以及不标准代码带来的问题，作为前端架构师，咱们就要思考三个问题：
- 如何制订标准？
- 如何对立团队的标准？
- 如何检测标准？
制订和对立标准
像下面给变量随便乱起名字的状况，在晚期的前端我的项目中十分常见。
因为晚期我的项目规模，团队规模无限，没有命名标准这种意识，随便起名貌似也没有太大的问题，只有不反复就好。然而随着前端我的项目规模越来越大，复杂度越来越高，不标准带来的问题越来越多，这种标准意识才缓缓的被器重起来。
通过社区的一直倒退，协定了命名蕴含以下几种标准：
- 下划线命名：
user_name - 中划线命名：
user-name - 小驼峰命名：
userName - 大驼峰命名：
UserName
有了这些标准，开发者们起名字的时候心里就有谱了。而且这些标准目前也被大多数开发者们承受，如果不依照标准命名，很可能会被共事吐槽喽！
当标准成为广泛共识之后，大家依照本人的爱好应用不同的标准，逐步造成了本人的编码习惯。在一个团队中，每个开发者往往各自有各自的编码习惯。
然而这又成为了问题。再拿变量举例：一个团队中，有的人习惯用下划线命名变量，如 user_name；有的人习惯用驼峰命名变量，如 userName。这两种命名形式都正确，都符合规范，然而会造成团队的代码格调凌乱，无奈对立。
那为什么要对立呢？
对立的益处有很多。比方咱们对立规定：命名变量用下划线，命名办法用小驼峰。那么在团队合作时，大家看到下划线就晓得这是一个变量，看到小驼峰就晓得这是一个办法。十个人的代码写进去是一个人的格调，不须要理解其余的编码格调，实现无障碍合作。
十个人的代码写出一个人的格调，说起来很现实，然而靠监督和盲目实现简直是不可能的。
怎么办呢？上面就是本文重点：祭出实现代码标准的三招神技。
神技一：ESLint
下面说到，团队合作开发我的项目，因为每个人的编码习惯不同，会写出各种各样的代码。这样的代码又乱又难以保护。
所以咱们心愿有这样一个工具，能够制订一套比拟残缺全面的标准，如果大家的编码不符合规范，程序就会正告甚至报错，用这种工具来倒逼团队成员恪守对立的代码格调。
这个工具是有的，咱们都听过，就是赫赫有名的 ESLint
ESLint 有两种能力：
- 查看代码品质，如是否有已定义但未应用的变量。
- 查看代码格调，换行，引号，缩进等相干的标准。
这两种能力简直涵盖了绝大部分代码标准，并且具体标准是可配置的，团队能够定制本人喜爱的代码格调。
定制标准后，我的项目运行或热更新时，ESLint 就会主动查看代码是否符合规范。
问：ESLint 查看与 TypeScript 查看有啥区别？
TypeScript 只会查看 类型谬误 ，而 ESLint 会查看 格调谬误。
尝试 ESLint
首先在我的项目下装置：
$ npm install eslint --save-dev而后运行命令初始化配置：eslint --init
eslint 是一个交互式命令，能够高低切换抉择适宜我的项目的选项；实现会生成 .eslintrc.json 文件。
根本配置
.eslintrc.json 的根本配置如下：
{
"env": {
"browser": true,
"es2021": true,
},
"extends": ["eslint:recommended"],
"parserOptions": {
"ecmaVersion": 12,
"sourceType": "module",
},
"rules": {},};这个根本配置蕴含了一套默认举荐的配置，定义在 eslint:recommended 这个扩大中。
React 配置
React 在默认配置的根底上，也有一套举荐的语法配置，定义在 plugin:react/recommended 这个插件中，如果你的前端框架是 React，要定义 eslint 标准，那么在根本配置上增加上面标记 + 号的配置即可：
{
"env": {
"browser": true,
"es2021": true
},
"extends": [
"eslint:recommended",
+ "plugin:react/recommended"
],
"parserOptions": {
+ "ecmaFeatures": {
+ "jsx": true
+ },
"ecmaVersion": 12,
"sourceType": "module"
},
+ "plugins": [
+ "react"
+ ],
"rules": {}};React + TS 配置
若要 React 反对 TS，还要加一些额定配置：
{
"env": {
"browser": true,
"es2021": true
},
"extends": [
"eslint:recommended",
"plugin:react/recommended"
+ "plugin:@typescript-eslint/recommended"
],
+ "parser": "@typescript-eslint/parser",
"parserOptions": {
"ecmaFeatures": {"jsx": true},
"ecmaVersion": 12,
"sourceType": "module"
},
"plugins": [
"react",
+ "@typescript-eslint"
],
"rules": {}};代码查看
下面定义好标准之后，咱们当初来写一段代码，并执行标准查看。
新建 index.js 文件，写入内容：
const a = '13'
function add() {return '1'}从 js 角度讲，这两行代码是没问题的。而后咱们运行查看命令：
$ npx eslint index.js这时会在控制台看到报错：
2:7 error 'a' is assigned a value but never used no-unused-vars
4:10 error 'add' is defined but never used no-unused-vars
2 problems (2 errors, 0 warnings)谬误的意思是变量 a 和函数 add 已申明但未应用，阐明代码不合乎约定的标准。这种异样也很常见，在脚手架构建的我的项目中应用 npm run dev 和 npm start 时就会执行下面的查看命令。
ESLint 标准
下面说过，ESLint 能够自定义查看标准，标准定义在 .eslintrc.json 配置文件的 rules 对象下。
比方，定义标准，字符串必须应用双引号：
{
"rules": {"quotes": ["error", "double"]
}
}定义好之后，如果你的代码中字符串应用单引号，ESLint 就会报错。
quotes 示意引号标准，是泛滥标准中的一个，它的值是一个数组。
数组第一项是谬误级别，是以下 3 个值之一：
"off" or 0– 敞开标准"warn" or 1– 正告级别标准"error" or 2– 谬误级别标准
数组第二项才是真正的标准，具体残缺的标准参考 这里
关上下面的网页，打绿钩的示意是已配置的。须要自定义间接写在 rules 里即可。
神技二：Prettier
上一步咱们用 ESLint 实现了标准的制订和查看。当开发人员实现一段代码保留时，我的项目会主动执行 eslint 查看命令查看代码，查看到异样后输入的控制台，待开发人员修复异样后能力持续开发。
如果你配置的编码标准比较复杂和严格，比方字符串必须单引号，代码结尾必须用分号，换行必须是 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": 100, // 一行的字符数，超过会换行（默认 80）"tabWidth": 2, // 每个 tab 相当于多少个空格（默认 2）"useTabs": true, // 是否应用 tab 进行缩进（默认 false）"trailingComma": "all", // 多行应用拖尾逗号（默认 none）"bracketSpacing": true, // 对象字面量的大括号间应用空格（默认 true）"jsxBracketSameLine": false, // 多行 JSX 中的 > 搁置在最初一行的结尾，而不是另起一行（默认 false）"arrowParens": "avoid" // 只有一个参数的箭头函数的参数是否带圆括号（默认 avoid）}定义好配置后，咱们在 index.js 文件中写入内容：
const a = "13"
function add() {return "1"}而后在终端运行格式化命令：
$ npx prettier --write index.js格式化之后，再看 index.js 文件变成了这样：
const a = '13';
function add() {return '1';}看到变动了吧，双引号主动变成了单引号，行结尾主动加了分号，刚好与配置文件中定义的标准统一。
喜大普奔！终于不必再手动修复不标准的代码了，一个命令就能搞定！
下面是格式化一个文件，当然也反对批量格式化文件。批量格式化通过含糊匹配查找文件，比拟罕用，倡议定义在 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
弱小的插件
VSCode 对咱们前端来说都不生疏，是咱们日日相伴的开发武器。以后 VSCode 简直对立了前端圈的编辑器，功能强大，倍受好评。
既然能失去如此宽泛的认可，那么就必然有它的优越性。VSCode 除了轻量启动速度快，最弱小的是其丰盛多样的插件，能满足不必使用者各种各样的需要。
在泛滥插件中，ESLint 就是十分弱小的一个。没错，这个插件就是咱们后面说到的神技第一招 ESLint 在 VSCode 上反对的同名插件。截图如下：
装置了这个插件之后，之前须要在终端执行 eslint 命令能力查看进去的异样，当初间接标记在你的代码上了！
即便是你敲错了一个符号，该插件也会实时的追踪到你谬误的中央，而后给出标记和异样揭示。这几乎大大晋升了开发效率，再也不必执行命令来查看代码了，看谁还说不优雅。
既然编辑器有 ESLint 插件，那是不是也有 Prettier 插件呢？猜对了，当然有插件，插件全名叫 Prettier - Code formatter，截图如下，在 VSCode 中搜寻装置即可。
Prettier 插件装置之后会作为编辑器的一个格式化程序。在代码中右键格式化，就能够抉择 Prettier 来格式化以后代码。
如果要想 Prettier 实现自动化，则还须要在编辑器中配置。
编辑器配置
VSCode 中有一个用户设置 setting.json 文件，其中保留了用户对编辑器的自定义配置。
这个配置十分丰盛，详见官网。首先咱们在这个配置当中将 Prettier 设置为默认格式化程序：
{
"editor.defaultFormatter": "esbenp.prettier-vscode",
"": {"editor.defaultFormatter":"esbenp.prettier-vscode"}
}设置好这一步之后，重点来了！ 咱们再来配置保留文件主动格式化：
{"editor.formatOnSave": true}配好之后，神奇的事件产生了：当你写完代码保留的时候，发现你正在编辑的文件立即被格式化了。也就是说，无论你的代码按不依照标准写，保留的时候主动帮你格式化成标准的代码。
这一步其实是保留文件的时候主动执行了格式化命令。因为咱们下面配置了默认格式化程序为 Prettier，当初又配了保留时格式化，相当于将文件保留和 prettier 命令连贯了起来。
到这一步，在三大神技的加持之下，咱们曾经实现了代码的主动查看与主动格式化，当初你编码的时候不须要思考什么格局标准的问题，只有失常保留，编辑器会主动帮你做好这些事件。
共享编辑器配置
下面咱们在编辑器通过一顿配置，终于实现了主动格式化。当初咱们要把这些设置同步给团队内的其余成员，该怎么办，难道要一个一个再配一遍？
别慌，不必这么麻烦。VSCode 的设置分为两类：
- 用户设置：利用于整个编辑器
- 工作区设置：利用于当前目录 / 工作区
这两类的配置内容是截然不同的，区别只是优先级的问题。如果你关上的我的项目目录蕴含工作区设置，那么这个工作区设置会笼罩掉以后的用户设置。
所以要想将设置同步给团队内的其余成员，咱们不须要去改变用户设置，只须要在我的项目目录下新建一个工作区设置即可。
增加工作区设置办法：在我的项目根目录下新建 .vscode/setting.json 文件，在这里写须要对立的编辑器配置。所以咱们把下面的 Prettier 配置写在这里即可实现共享。
附录：命名和我的项目构造标准
下面介绍了代码标准，代码检查和代码格式化，对立代码格调曾经很全面了。
在团队开发过程当中，咱们也积攒了一些并不会写在配置文件里的标准，这些标准在一个团队当中也是十分重要。这部分算是咱们的团队标准的分享吧。
次要说两局部：命名标准和我的项目构造标准。
命名标准
命名标准，文章结尾也说了，变量的四种命名标准。然而什么中央用哪种标准，咱们也是有约定的。
- 变量命名：下划线
user_id - CSS-Class 命名：中划线
user-id - 办法函数命名：小驼峰
userId - JS-Class 命名：大驼峰
UserId - 文件夹命名：中划线
user-id - 文件夹下组件命名：中划线
user-id - 组件导出命名：大驼峰
UserId
我的项目构造标准
我的项目构造标准次要是指 src 文件夹下的构造组织。
|-- src
|-- index.tsx # 入口文件
|-- assets # 动态资源目录
|-- components # 公共组件目录
| |-- header
| | |-- index.tsx
| | |-- index.less
|-- stores # 状态治理目录，与 pages 构造对应
| |-- admins
| | |-- index.tsx # 状态文件
| | |-- types.ts # 定义状态类型
| |-- index.tsx
|-- pages # 页面目录，与 stores 构造对应
| |-- admins
| | |-- index.tsx
| | |-- index.less
|-- request
| |-- index.ts # axios 实例，全局申请解决
|-- router
| |-- home.tsx
| |-- index.tsx
| |-- root.tsx
|-- styles # 全局款式
| |-- common.less
| |-- index.less
|-- utils # 工具目录
|-- index.ts往期精彩
本专栏会长期输入前端工程与架构方向的文章，已公布如下：
- 前端架构师的 git 功力，你有几成火候？
- 纯 Git 实现前端 CI/CD
如果喜爱我的文章，请点赞反对我吧！也欢送关注我的专栏，感激🙏🙏