不积跬步无以至千里，不积小流无以成江海。我们从最简单也是最能影响我们实际工作效率的地方开始，而说到这个，能够第一时间想到的就是能够一直默默为我们付出的，也是团队协作中必备的工具: 代码规范工具了。

代码规范工具，一般意义上可以分为两种: 代码格式化工具与代码静态检查工具两种。

代码格式化工具

代码格式化工具，字面意思就是格式化代码的工具，每个人的编码习惯都有所不同，有的喜欢空格缩进有的Tab缩进，甚至空格缩进还能细分两个空格和四个空格。而对于像是 JavaScript 这样不严格的语言来说，行尾加不加分号也会划分成不同的流派。争论各个流派(编码风格)的好坏是没有意义的，而口头的约束也是难以达成统一，因此，代码格式化工具应运而生。而一般的代码编辑器(editor)都自带有代码格式化能力，有的甚至会绑定了保存自动进行格式化。

那么就是说我们不需要去关心代码格式化相关的问题了么？并不是的，特别是团队协作，或者开源协作上，大家用的代码编辑器(editor)可能不尽相同。有的同学喜欢用vscode，有的同学喜欢用webstorm，习惯传统的同学也会选择vim或者emacs。ide之间尚有偏好设定，那么谁来做一个决策到底用哪种风格呢？因此需要一个第三方的、环境无关、编辑器无关的"裁判"来做最终决策。

Prettier

目前前端业界比较流行的，经过多次淘汰最终获胜的解决方案是 Prettier(https://prettier.io/), Prettier的使用也非常简单

安装

npm install -D prettier # 安装prettier到devDependencies

配置

在项目的根目录下创建一个 .prettierrc.json 文件，然后写入:

{}

是的，你甚至不需要写入任何额外的内容，因为prettier自带的会为你选择一套默认的也是流行的配置方案。

接下来我们可以进行一次简单的格式化了，当然在此之前如果我们需要排除一部分的文件不需要格式化的话我们可以自行建一个 .prettierignore 文件用于忽略格式化。prettier会自动继承 .gitignore 和 .eslintignore 且语法是保持一致的。因此大部分情况下你是不需要再额外的再为prettier进行额外的忽略的。

接下来可以使用命令行来帮助你使用prettier了

npx prettier --write .

当然，prettier提供了很多已经简化过了的配置，完整的配置信息可以看官方文档: https://prettier.io/docs/en/options.html

这边给出一个配置文件用于参考:

{

"printWidth": 80, // 推荐列宽80个字符

"tabWidth": 2, // 缩进宽度2字符

"useTabs": false, // 不使用tab缩进

"semi": true, // 每行句末带分号

"singleQuote": true, // 对字符串使用单引号而不是双引号

"trailingComma": "es5", // 在换行数组/对象结束带分号，方便diff

"bracketSpacing": true, // 对象字面量之间增加空格

"arrowParens": "always", // 箭头函数总是带括号: 偏好(x) => x 而不是 x => x

"bracketSameLine": false // 换行的xml结尾的>符号放于下一行而不是同行

}

在线演示

通过在线演示来快速验证也是一种比较好的方式，在某些场合下我们使用命令行工具会显得过于臃肿和繁琐，prettier提供了在线平台帮助我们进行快速预览: https://prettier.io/playground/

集成到editor中

prettier已经支持了大部分常见的代码编辑器如:

vscode(通过插件https://github.com/prettier/prettier-vscode)
webstorm(内置)
vim(https://github.com/prettier/vim-prettier)
...

简单配置后我们可以实现保存自动格式化，且因prettier本身的优化其执行效率还是很高的。

editorconfig

前面介绍了现在比较流行的代码格式化工具prettier，那么就不得不提到在另一个方向做出努力的工具 editorconfig 了。

相比他的同行在各种语言，各种规范上做出的努力，editorconfig做的事情更加纯粹也更加简单。他仅仅是统一了不同编辑器在配置上的区别，比如缩进是tab还是空格，行末到底是lf还是crlf，文件结尾是否保留空行之类非常"简单"的事情。

可以注意到的是，这些规则是语言无关、系统无关的，它仅仅是统一了不同编辑器在不同系统下的行为。简单而实用。

代码静态检查工具

代码静态检查工具，其实也包含了格式化工具，主要目的是对源代码进行静态分析，然后修复或者发现一些通过一些规则能够发现的问题。当我们涉及到更多团队协作的细节以后，该工具的收益才会慢慢显示出来。如果你的团队还在对一些细节写法产生一些分歧，那么最好的做法就是使用代码静态检查工具对代码进行处理。很多细节的分歧其实是两者皆可的，不论选用哪种方案都是无关紧要的。而其真正的问题是代码中可能会同时出现两种方案，而静态检查就确保了整个仓库都会使用统一的方案进行，从而避免不必要的规范差异。

纵观华夏上下五千年，秦始皇最伟大的地方就在于"书同文，车同轨"，规范的统一是重中之重。

eslint

eslint就是目前web前端非常流行的一个代码静态检查工具，他包含了大部分你能想到和你不能想到的js代码规则，涉及到整个代码体系的方方面面。同时，插件化的设计让他能够引入来自更多其他开发者的规则，真正做到让开发者专注于自己的代码中。

想要快速集成也非常简单，eslint官方提供了一个快速集成的方式，只需要在你的项目根目录下执行以下命令即可：

npm init @eslint/config

接下来有一段交互式的安装引导，按照引导程序一步步进行下去即可

执行命令 eslint ./src/*/.{ts,tsx} 即可开始第一次的代码静态检查，默认会添加一些官方推荐的规则配置。

为了快捷使用也可以添加到npm scripts 中:

{

//...

"scripts": {

"lint": "eslint ./src/**/*.{ts,tsx}",

//...

}

这样我们就可以通过执行 npm run lint 来快速运行代码静态检查，一般来说我们会简单的称呼这个过程为lint 。这个操作在其他语言也是有的，如python的 pylint , go的 golint 等。

如果是一个维护比较久的项目的话可能会在第一次引入eslint 的时候会产生大量的报错。没有关系，这是一个正常的现象。耐心的将他们一个个修复，或者临时在规则中将其改为warning 留在后期修复都是可以的，具体要如何决策需要看具体情况来分析。

修改规则的方式很简单。只需要在生成的.eslintrc 文件的rules字段添加相关规则的变更即可。

首先找到报错的规则:

如图所示规则为最右侧灰字部分，这条规则是react/prop-types .

在react 的推荐用法是推荐使用 prop-types 库对输入参数进行校验的，但是如果使用的是 Typescript 对类型做静态校验的话那么这一步是可选的。

那么在这里我们修改 .eslintrc 文件将其改为 off

{

// ...

"rules": {

"react/prop-types": "off"

// ...

}

如果仅仅是想要临时绕过不想处理也可以使用 warn 来标记，这样eslint 还是为抛出警告但是不会输出错误。这在我们接下来的CI集成中非常重要。

集成到editor中

我们还可以使用编辑器的相关插件来在编辑器中直接引入eslint 插件对代码进行检查。

这里直接以vscode 为例，只需要在插件面板中搜索 eslint 即可安装。

总结

在本节内容，我们学会了如何使用代码格式化与代码静态检查工具，特别的了解了一下目前比较流行的prettier 和eslint 基本使用。

接下来我们就要将其集成到我们的工作流中，让其成为项目代码质量保证的一部分。

小思考: 在平时的协作中有遇到什么代码规范上的问题？又是如何解决的呢？

【CICD】从代码规范工具开始的全部评论