如何快速写出风格统一的代码(ESLint+Prettier+EditorConfig)

当大家在公司工作时,不可能永远是一个人维护一个项目,当多个人参与一个项目,每个人写的代码风格不一样,甚至是使用的编辑器不一样,都会导致最终产生的代码千差万别,后期维护项目的时候,如果进行了自动格式化代码,则会导致浪费大量的时间用来解决冲突,加大项目的维护难度。

那么如何能够快速的写出风格统一的代码成为了当务之急。
在工程化项目里,最理想的方法当然是通过借用可灵活配置的工具,实现自动化解决,这里介绍的解决方案是EditorConfig+Prettier+ESLint 的组合。

  • EditorConfig: 跨编辑器和IDE编写代码,保持一致的简单编码风格;
  • Prettier: 专注于代码格式化的工具,美化代码;
  • ESLint:作代码质量检测、编码风格约束等;

EditorConfig

如果使用的是Vscode,先安装插件 EditorConfig for vs code
然后在项目根目录下新建.editorconfig文件

打开文件时,EditorConfig插件会在打开的文件的目录中以及每个父目录中查找名为.editorconfig的文件。如果到达根文件路径或找到root = true的EditorConfig文件,将停止对.editorconfig文件的搜索。
离文件最近的配置规则生效,优先级更高;一般在根目录设置一个配置文件即可。
在文件开头的root = true表示配置文件以此为准

[*]表示匹配所有的文件

一、常用属性配置

  • 1、root : 是否是顶级配置文件,设置为true的时候才会停止搜索.editorconfig文件
  • 2、charset<"latin" | "utf-8" | "utf-8-bom" | "utf-16be" | "utf-16le"> : 文件编码格式
  • 3、indent_style<"tab" | "space"> : 缩进方式
  • 4、indent_size : 缩进大小
  • 5、end_of_line<"lf" | "cr" | "crlf"> : 换行符类型
  • 6、insert_final_newline : 是否让文件以空行结束
  • 7、trim_trailing_whitespace : 是否删除行尾空格
  • 8、max_line_length : 最大行宽。

EditorConfig包含的内容比较少,主要是配置我们的编辑器,编写代码时的简单规则,不足以满足项目更多需求。

Prettier

Prettier只关注格式化,并不具有lint检查语法等能力。它通过解析代码并匹配自己的一套规则,来强制执行一致的代码展示格式。
它在美化代码方面有很大的优势,配合ESLint可以对ESLint格式化基础上做一个很好的补充。

还是以VSCode为例,首先安装Prettier插件。
VSCode内置的代码格式化工具可以指定为由Prettier接管,此时右下角会显示为Prettier。可以自行配置格式化触发机制:换行时格式化、保存文件时格式化、还是自行快捷键触发;
默认情况下我都是使用默认的手动触发。
当在编辑器里格式化未生效时,可以在.settings.json里检查对应文件格式指定的格式化程序并调整就可以:

"[jsonc]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[vue]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[css]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[less]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
}

这样在VSCode编辑器里,触发文件格式化时就能根据配置自动美化格式代码。
可以在VSCode 首选项-设置-扩展或.settings.json中更改通用配置;
当然还可以在具体项目根目录设置.prettierrc单独配置;
比如以下一些配置:

{
  // 设置强制单引号
  "singleQuote": true,
  // 为多行数组的非末尾行添加逗号 es5的对象,数组等
  "trailingComma": "es5",
  // 每行最大宽度 100
  "printWidth": 100,
  // 设置语句末尾不加分号
  "semi": false,
  // jsx中使用单引号
  "jsxSingleQuote": true,
}

EsLint

ESLint 是一个在 JavaScript 代码中通过规则模式匹配作代码识别和报告的插件化的检测工具,它的目的是保证代码规范的一致性和及时发现代码问题、提前避免错误发生。
ESLint 的关注点是代码质量,检查代码风格并且会提示不符合风格规范的代码。除此之外 ESLint 也具有一部分代码格式化的功能。

使用方法:
1.安装:ESLint 可以安装在当前项目中或全局环境下,但因项目间存在的差异性,我们一般会将它安装在当前项目中。安装

yarn add --save-dev eslint

2.安装插件和解析器
假如项目中使用了TypeScript和React,则安装:

yarn add --save-dev typescript @typescript-eslint/parser
yarn add --save-dev eslint-plugin-react @typescript-eslint/eslint-plugin

其他的插件和解析器请根据实际项目需要安装。

3.创建配置文件
我们在项目的根目录下创建一个 .eslintrc.js,内容如下:


module.exports = {
    parser: '@typescript-eslint/parser',
    plugins: ['react','@typescript-eslint'],
    rules: {
        // 禁止使用 var
        'no-var': "error",
        // 优先使用 interface 而不是 type
        '@typescript-eslint/consistent-type-definitions': [
            "error",
            "interface"
        ]
    }
}

如果是用脚手架工具创建的项目,创建的时候勾选了eslint,则上面的3步操作,都会自动完成。

rules属性是一个对象,对象中包含很多规则,规则的值主要有0,1和2这三种:
0 或者"off" ,表示关闭规则。
1或者"warn" ,打开规则,并且将规则视为一个警告(并不会导致检查不通过)。
2或者"error" ,打开规则,并且将规则视为一个错误 (退出码为1,检查不通过)。
在行内书写规则,需要写在/* eslint ... */

我们需要的绝大多数规则都是在这个rules对象中:

比如说我们想要修改代码缩进,就在配置文件中的rules对象中添加一个属性:
使用浏览器默认配置'indent':0
使用两个空格作缩进"indent": ["error", 2]
使用Tab作为缩进"indent": ["error", "tab"]

比如说我们想要每行代码末尾都要有分号:'semi':["error","always"],这样,你的 js 代码每一个表达式的结尾就应该以分号结尾,否则 eslint 会给出错误提示。
如果你希望 eslint 不检查分号这一项,这个时候结尾的分号,你加也可以,不加也可以,在 rules 字段配置:"semi": [0, "never"],

常用的规则:
与Javascript代码中可能的错误有关的规则
禁止条件表达式中出现模棱两可的赋值操作符:no-cond-assign
禁用console:no-console
禁止在条件中使用常量表达式:no-constant-condition
禁用 debugger :no-debugger
禁止 function 定义中出现重名参数 :no-dupe-args
禁止对象字面量中出现重复的 key :no-dupe-keys
禁止出现重复的 case 标签 :no-duplicate-case
禁止出现空语句块 :no-empty
禁止对 catch 子句的参数重新赋值 :no-ex-assign
禁止不必要的布尔转换 :no-extra-boolean-cast
禁止不必要的括号 :no-extra-parens
禁止不必要的分号 :no-extra-semi
禁止对 function 声明重新赋值 :no-func-assign
禁止在嵌套的块中出现变量声明或 function 声明 :no-inner-declarations
禁止在字符串和注释之外不规则的空白 :no-irregular-whitespace
禁止把全局对象作为函数调用 :no-obj-calls
禁用稀疏数组 :no-sparse-arrays
禁止直接使用Object.prototypes 的内置属性 :no-prototype-builtins
禁止出现令人困惑的多行表达式 :no-unexpected-multiline
禁止在return、throw、continue 和 break语句之后出现不可达代码 :no-unreachable
要求使用 isNaN() 检查 NaN :use-isnan
强制 typeof 表达式与有效的字符串进行比较:valid-typeof

下面这些规则是关于最佳实践的,帮助你避免一些问题:
强制数组方法的回调函数中有 return 语句 :array-callback-return
强制把变量的使用限制在其定义的作用域范围内 :block-scoped-var
指定程序中允许的最大环路复杂度 :complexity
要求 return 语句要么总是指定返回的值,要么不指定 :consistent-return
强制所有控制语句使用一致的括号风格 :curly
要求 switch 语句中有 default 分支 :default-case
强制在点号之前和之后一致的换行 :dot-location
强制在任何允许的时候使用点号 :dot-notation
要求使用 === 和 !== :eqeqeq
要求 for-in 循环中有一个 if 语句 :guard-for-in
禁用 alert、confirm 和 prompt :no-alert
不允许在 case 子句中使用词法声明 :no-case-declarations
禁止 if 语句中有 return 之后有 else :no-else-return
禁止出现空函数 :no-empty-function
禁止在没有类型检查操作符的情况下与 null 进行比较 :no-eq-null
禁用 eval() :no-eval
禁止不必要的 .bind() 调用 :no-extra-bind
禁止 case 语句落空 :no-fallthrough
禁止数字字面量中使用前导和末尾小数点 :no-floating-decimal
禁止使用短符号进行类型转换 :no-implicit-coercion
禁止在全局范围内使用 var 和命名的 function 声明 :no-implicit-globals
禁止 this 关键字出现在类和类对象之外 :no-invalid-this
禁用不必要的嵌套块 :no-lone-blocks
禁止在循环中出现 function 声明和表达式 :no-loop-func
禁用魔术数字 :no-magic-numbers
禁止使用多个空格 :no-multi-spaces
禁止使用多行字符串 :no-multi-str
禁止在非赋值或条件语句中使用 new 操作符 :no-new
禁止对 Function 对象使用 new 操作符 :no-new-func
禁止对 String,Number 和 Boolean 使用 new 操作符 :no-new-wrappers
不允许对 function 的参数进行重新赋值 :no-param-reassign
禁止使用 var 多次声明同一变量 :no-redeclare
禁止在 return 语句中使用赋值语句 :no-return-assign
禁止使用 javascript: url :no-script-url
禁止自我赋值 :no-self-assign
禁止自身比较 :no-self-compare
禁用逗号操作符 :no-sequences
禁用一成不变的循环条件 :no-unmodified-loop-condition
禁止出现未使用过的表达式 :no-unused-expressions
禁止不必要的 .call() 和 .apply() :no-useless-call
禁止不必要的字符串字面量或模板字面量的连接 :no-useless-concat
要求所有的 var 声明出现在它们所在的作用域顶部:vars-on-top

与使用严格模式和严格模式指令有关规则:
要求或禁止使用严格模式指令 :strict

与变量声明有关规则:
要求或禁止 var 声明中的初始化 : init-declarations
不允许 catch 子句的参数与外层作用域中的变量同名 :no-catch-shadow
禁用特定的全局变量 :no-restricted-globals
禁止 var 声明 与外层作用域的变量同名 :no-shadow
禁用未声明的变量,除非它们在 /global / 注释中被提到 :no-undef
禁止将变量初始化为 undefined :no-undef-init
禁止出现未使用过的变量 :no-unused-vars
不允许在变量定义之前使用它们 :no-use-before-define

关于Node.js 或 在浏览器中使用CommonJS 的规则:
要求 require() 出现在顶层模块作用域中 :global-require
要求回调函数中有容错处理 :handle-callback-err
禁止混合常规 var 声明和 require 调用 :no-mixed-requires
禁止调用 require 时使用 new 操作符 :no-new-require
禁止对 dirname 和 filename进行字符串连接 :no-path-concat
禁用指定的通过 require 加载的模块 :no-restricted-modules

如何保存代码的时候自动格式化代码

vscode 中写完代码 Ctrl + s 保存即可格式化代码 或者 (Shift+Alt+f)
找到settings.json,settings.json里所有的配置都是在一个对象中,给这个对象添加属性

"editor.fontSize": 14,
"editor.formatOnType": true,
"editor.formatOnSave": true

editor.fontSize可以修改编辑器的字号,默认是14号,修改之后保存即可。

Prettier和EsLint的区别

prettier主要功能是用来做代码风格格式化的,eslint主要是做语法验证的,这2个一开始我也不懂,而且有部分像是否加分号,字符串使用单引号还是双引号这些他们都可以配置

我是这么理解的eslint是给你指出问题的,它告诉你你的代码有哪里不规范然后让你自己改(它可以帮你改一小部分),而prettier是你给它指定规则,然后它帮你完成格式化,它只有一个功能就是根据你的规则格式化代码,

因为eslint有一部分代码它也可以帮你格式化,并且使用了prettier-eslint后它的权重比prettier高,所以你给prettier设置的规则不生效,就要考虑是不是eslint影响了它

beautify和prettier

beautify和prettier都是能够格式化代码的插件
.jsbeautifyrc文件添加配置代码,也是在settings.json中添加vscode对beautify的使用,但是因为我们选用的Prettier,自然就舍弃Beautify了
Vscode编辑器里卸载掉Beautify插件

LF和CRLF引起的Git冲突

CRLF 是 carriage return line feed 的缩写,中文意思是回车换行。
LF 是 line feed 的缩写,中文意思也是换行。
它们都是文本换行的方式。

CRLF: "\r\n", windows系统环境下的换行方式
LF: "\n", Linux系统环境下的换行方式

他们之间的不同经常会导致不同会导致使用不同系统的同事之间的代码冲突问题。
在你使用git拉取代码的时候,git会自动将代码当中与你当前系统不同的换行方式转化成你当前系统的换行方式,从而造成这种冲突。
前面有说使用EditorConfig,在配置里添加end_of_line = lf可以让项目里的文件改为统一的LF。
在git提交代码的时候,git status查看有对应文件的修改,但是git diff的时候查看不到修改内容的时候,很有可能是当前文件的换行方式发生了变化,虽然在绝大多数情况下这并不会引起冲突,但在团队协作的过程中,每次提交修改的代码应尽量减少修改不必要的文件,这是一个良好的习惯。

你可能感兴趣的:(如何快速写出风格统一的代码(ESLint+Prettier+EditorConfig))