文章目录
一、EditorConfig
EditorConfig是帮助跨各种编辑器和ide处理同一项目的多个开发人员维护一致的编码风格,文件中的设置会优先于用户/工作区设置，在开发过程中，可以通过对编辑器配置编码规则在开发过程就对代码的风格进行初步的统一。
有些编译器自带对.editorConfig这个文件的支持（可以识别这个文件中所配置的规则），有些则需要自行安装插件，VS Code需要安装插件EditorConfig for VS CODE
配置方法：在项目的根目录下创建.editorConfig文件，配置如下：
# .editorConfig文件配置：
# 当打开一个文件时，EditorConfig插件会在打开的文件目录和每个父目录中查找一个名为.editorConfig的文件。
# 如果找到了根文件路径或者找到了带有root=true的EditorConfig文件，那么对.editorConfig文件的搜索就会停止。
root = true
# 匹配的文件
[*]
# 缩进的类型 [space | tab]
indent_style = space
# indent_size应该设置为tab的大小，制表符的大小应该是tab_width(如果指定的话);否则为编辑器设置的选项卡大小。这些值不区分大小写。
# tab_width: 设置为一个整数，定义用于表示tab的列数。默认为indent_size的值，通常不需要指定。
indent_size = 2
# 定义换行符 [lf | cr | crlf] ,这些值不区分大小写
end_of_line = lf
# 编码格式。支持latin1、utf-8、utf-8-bom、utf-16be和utf-16le，不建议使用uft-8-bom。
charset = utf-8
# 将其设置为true以删除文件中换行符之前的所有空格字符，将其设置为false以确保不删除换行符。
trim_trailing_whitespace = true
# 文件是否以一个空白行结尾 [true | false]
insert_final_newline = true
可以查阅官方根据需要再进行个性化配置EditConfig
二、ESLint
.eslintrc
ESLint是在ECMAScript/JavaScript代码中按照语法规则识别并且并给出报告的代码检测工具，它的作用是保证代码语法的一致性和避免错误。主要针对语法方面（比如无效变量，变量未申明使用等语法）的是无效的，这方面可以交给ESLint。
使用ESLint，必须要安装它，可以本地安装或全局安装：
// 本地安装
npm install eslint --save-dev
// 全局安装
npm install eslint --global
可以进入 ./node_modules/.bin/eslint 目录执行 --init 创建，或者自己创建一个 .eslintrc 文件,或者直接在 package.json 文件中通过 eslintConfig 字段指定配置，ESLint 会查找和自动读取它们。
./node_modules/.bin/eslint --init
.eslintrc.js配置文件可参考如下配置如下：
module.exports = {
// extend 属性可以说指定配置的字符串
// 这里'plugin:vue/essential'是eslint-plugin-vue插件关于vue的配置（要install eslint-plugin-vue）
// '@vue/prettier' 是@vue/eslint-config-prettier插件关于vue的美化工具（要install @vue/eslint-config-prettier）
"extends": ['plugin:vue/essential', '@vue/prettier'],
// 使用prettier进行处理，对prettier处理后的代码eslint再进行语法检测
"plugins": [
"prettier"
],
// 可根据需要配置额外规则,
//"off" 或者 0：关闭规则。
//"warn" 或者 1：打开规则，并且作为一个警告（不影响exit code）。
//"error" 或者 2：打开规则，并且作为一个错误（exit code将会是1）。
"rules": {
"quotes": ["error", "double"], //强制使用一致的单引号
"semi": ["error", "always"], //强制行尾部分号
// 可以覆盖基本配置规则的默认选项
"comma-dangle": ["error", "always"], //数组和对象键值对最后一个必须带逗号
"no-use-before-define": 2 //不允许在变量定义之前使用它们。
// 禁用基本配置中的规则
"no-console": "off", //关闭禁用 console
}
}
.eslintignore
配置需要忽略检查的文件和目录，避免对不必要的文件也进行校验增加检测时长，参考配置如下：
# .eslintignore文件
/dist/
/node_modules/
/static/
/public/
三、Prettier
.prettierrc
Perttier可以美化代码，主要是书写规则方面的。
使用prettier需要先安装，可以局部安装或全局安装：
# 局部安装
npm install --save-dev --save-exact prettier
# 全局
npm install --global prettier
perttier的执行可以配置到 .eslintrc.js文件的plugin中，当成eslint的插件来使用，.prettierrc.js配置如下：
module.exports = {
//每行最多多少个字符换行默认80
printWidth: 150,
//tab缩进大小,默认为2
tabWidth: 2,
//使用分号, 默认true
semi: true,
//使用单引号, 默认false(在jsx中配置无效, 默认都是双引号)
singleQuote: true,
//行尾逗号,默认none,可选 none|es5|all
trailingComma: 'none',
// 对象中的空格 默认true
// true: { foo: bar }
// false: {foo: bar}
bracketSpacing: true,
// JSX标签闭合位置 默认false
// false: <div
// className=""
// style={{}}
// >
// true: <div
// className=""
// style={{}} >
jsxBracketSameLine: true,
// 箭头函数参数括号 默认avoid 可选 avoid| always
// avoid 能省略括号的时候就省略 例如x => x
// always 总是有括号
arrowParens: 'avoid',
//行结尾的风格<auto | lf | crlf | cr>
endOfLine: 'auto'
};
.prettierignore.js
使用 prettierignore 来对不需要进行检查的文件夹进行忽略,配置如下：
/dist/
/node_modules/
/static/
/public/
四、StyleLint
.stylelintrc.js
对于样式部分的检查可以使用styleLint，它可以识别scss语法
需要安装stylelint包
npm install -g stylelint --save-dev
在项目中添加配置文件".stylelintrc.js"
module.exports = {
extends: ['stylelint-config-prettier', 'stylelint-config-standard', './node_modules/prettier-stylelint/config.js'],
rules: {
// 定义一些适合团队约定的规则
'no-empty-source': null,
'color-hex-case': null,
'rule-empty-line-before': null
}
};
.stylelintignore.js
使用 stylelintignore 来对不需要进行检查的文件夹进行忽略,配置如下：
/dist/
/node_modules/
/static/
/public/
五、hushy+Lint-staged+Commitlint
上面几部是在开发的过程进行格式化，这最后一步是在代码最终提交到远程的时候进行的最后一次把关，保证提交的代码是符合规范的。
其中，husky提供git的钩子功能，可以在git的各个阶段执行相关操作，利用hushy在预提交代码的时候进行Lint检查 ，需要npm安装husky；
npm install husky --save-dev
lint-staged 工具是用来识别被加入到stage区文件，使用它来避免对项目中进行全项目扫描所会增加了检查复杂度和时长，我们只需要检查我们要提交的代码就可以了。需要安装lint-staged；
npm install lint-staged --save-dev
Commitlint用于检查我们的commit message是否符合提交规范，如果不符合，则直接拒绝提交 。
npm install -g @commitlint/cli @commitlint/config-conventional
@commitlint/cli 是git commit lint工具
@commitlint/config-conventional 可共享的commitlint配置执行常规提交配置，校验时不满足规则则会退出
这里的配置需要三步：
第一步：这里把提交检测配置在在package.json中，配置如下：
// Git钩子对应的操作
"husky": {
"hooks": {
"pre-commit": "lint-staged" // 在代码commit前执行将加入到stage暂存区的文件进行检查，按照"lint-staged"中的规则进行检查
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
},
// 对staged的文件进行lint，避免对整个项目进行lint代码庞大且缓慢
"lint-staged": {
"linters": {
"src/**/*.js": [ // 匹配.js文件一下命令
"eslint --fix", // 执行eslint进行扫描进行fix
"prettier --write", //执行prettier脚本,对代码镜像格式化
"git add" //上述两项任务完成后对代码重新add。
],
"src/**/*.vue": [
"eslint --fix",
"stylelint --fix",
"prettier --write",
"git add"
],
"src/**/*.scss": [
"stylelint --syntax=scss --fix",
"prettier --write",
"git add"
],
"ignore": [
"/dist/",
"/node_modules/",
"/static/",
"/public/"
]
}
},
第二步：在项目目录下创建 commitlint.config.js 文件，加入：
/**
build：主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交
ci：主要目的是修改项目继续集成流程(例如 Travis，Jenkins，GitLab CI，Circle等)的提交
docs：文档更新
feat：新增功能
fix：bug 修复
perf：性能优化
refactor：重构代码(既没有新增功能，也没有修复 bug)
style：不影响程序逻辑的代码修改(修改空白字符，补全缺失的分号等)
test：新增测试用例或是更新现有测试
revert：回滚某个更早之前的提交
chore：不属于以上类型的其他类型
**/
module.exports = {extends: ['@commitlint/config-conventional']}; // 这里使用@commitlint/config-angular默认配置
知识拓展
代码规范标准 Airbnb 和 Standard
目前比较受欢迎的代码规范有标准AirBnB和Standard.AirBnb是Github上star人数是最多的，目前已经95k+了；而Standard的star人数有23k+。
网上很多都说Airbnb的规范比Standard更为严格，那究竟是怎么严格呢？
比较了一下二者的规则文档，区别有：
- Airbnb有接近160条的规则，而Standard有不到130条规则；
- Airbnb默认是使用要分号；而Standard则默认不使用分号；
- Standard的规则多是比较常见，易于理解和修改的格式或语法规范；而Airbnb规定得更为具体和细致，举几个例子大家感受一下：
- const 和 let 都只存在于它定义的那个块级作用域；
- 当创建一个带有动态属性名的对象时，用计算后属性名；
- 不要直接调用Object.prototype上的方法，如hasOwnProperty, propertyIsEnumerable, isPrototypeOf；
- 对象浅拷贝时，更推荐使用扩展运算符[就是…运算符]，而不是Object.assign。获取对象指定的几个属性时，用对象的rest解构运算符[也是…运算符]更好；
- 用命名函数表达式而不是函数声明；
- 用默认参数语法而不是在函数里对参数重新赋值；
- Numbers: 用 Number 做类型转换，parseInt转换string常需要带上基数；
附上Github链接地址可以查询：
AirBnB（详细可见AirBnb的中文版Github）
Standard（详细可见Standard的中文版Github）
忽略校验
对于规范中的规则，可以通过配置修改，也在代码中可以使用注释禁用ESLint规则检测。
有几种在代码中禁用ESLint语法校验的方式：
// 一、代码块
// 1：禁用代码块
/* eslint-disable */
这里被包裹的代码语法不会被检测
/* eslint-enable */
// 2： 没有/* eslint-enable */，/* eslint-disable */后的所有代码都会禁止规则校验
/* eslint-disable */
// 3：注释后禁用具体的规则，no-unneeded-ternary是三元运算，no-console是console输出
/* eslint-disable no-console */
/* eslint-disable no-unneeded-ternary,no-console */
// 二、禁用下一行语法检测（"//"是包含在使用语句中的）
// 1：关闭下一行校验
// eslint-disable-next-line
// 2：禁用下一行具体的语法检测
// eslint-disable-next-line no-alert
// 三、关闭当前行的代码语法检测
// 1：关闭当前行的检测
some code // eslint-disable-line
//2：针对当前行的某一具体规则禁用eslint检查
some code // eslint-disable-line no-alert
相比较而言，AirBnB会更加严格，对很多具体的语法都进行了更为严格的限制。对强规范代码可能会使代码看起来更优雅和统一，有更强的一致性，但是也会使你写代码受到更多的约束。
如果你的项目是后引入规范的项目，尤其是大项目来说，那就可能会让人头疼了。
所以对代码的规范程度孰优孰劣，需要根据实际情况进行抉择了。