关于vue.js:标准化编程规范解决方案之ESLint

3次阅读

共计 2390 个字符，预计需要花费 6 分钟才能阅读完成。

工欲善其事，必先利其器

对于大型的企业级我的项目而言，通常状况下咱们都是一个团队很多人来独特进行开发的。而又因为团队人员对技术了解上的参差不齐，所以就会导致呈现一种状况，那就是《一个我的项目无奈具备对立的编程标准，导致我的项目的代码像多个不同材质的补丁拼接起来一样》

构想一下，上面的这段代码有一个团队进行开发，因为没有具备对立的代码规范，所以生成了上面的代码：

这段代码能够失常运行没有问题，然而整体的代码构造却十分的难看。

有的中央有空格进行宰割，有的中央却没有

有的中央是单引号，有的中央却是双引号

有的中央有分号，有的中央没有分号

….
这样的我的项目尽管能够失常运行，然而如果把它放到大厂的我的项目中，的确 不及格 的，它会被认为是 不可保护、不可扩大的代码内容

那么所谓的大厂规范的代码构造应该是什么样子的呢？

咱们把下面的代码进行一下修改，做一个比照：

批改之后的代码具备了对立的标准之后，是不是看起来就难受多了！

并且以上所列举进去的只是《编程标准》中的一小部分内容！

那么有些同学可能就会说了，你列举进去这些编程标准有什么用啊！

哪怕你写上一部书，咱们一个团队这么多人，总不能指望所有人都看一遍，并且严格的恪守你所说的标准吧！

说的没错！指望人被动的恪守这些标准不太事实

那怎么办呢？

那么咱们可不可以另辟蹊径，让程序主动解决规范化的内容呢？

答案是：能够的！

本系列中我会为大家分享，如何自动化的对代码进行标准，其中次要包含：

编码标准
git 标准

两大类

在咱们去创立我的项目的时候，脚手架工具曾经帮忙咱们装置了 ESLint 代码检测工具。

对于 ESLint 的小名，同学们或多或少的应该都据说过，只不过有些同学可能理解的多一些，有些同学理解的少一些。

那么本大节咱们就先来聊一下，这个赫赫有名的代码检测工具 ESLint

首先 ESLint 是 2013 年 6 月 创立的一个开源我的项目，它的指标非常简单，只有一个，那就是 提供一个插件化的 javascript 代码检测工具 ，说白了就是做 代码格局检测应用的

在咱们以后的我的项目中，蕴含一个 .eslintrc.js 文件，这个文件就是 eslint 的配置文件。

随着大家对代码格局的规范性越来越器重，eslint 也逐步被更多的人所接管，同时也有很多大厂在原有的 eslint 规定根底之上进行了一些延长。

咱们在创立我的项目时，就进行过这样的抉择：

? Pick a linter / formatter config: 
  ESLint with error prevention only // 仅蕴含谬误的 ESLint
  ESLint + Airbnb config // Airbnb 的 ESLint 延长规定
  ESLint + Standard config // 规范的 ESLint 规定

咱们以后抉择了 规范的 ESLint 规定，那么接下来咱们就在该规定之下，看一看 ESLint 它的一些配置都有什么？

关上我的项目中的 .eslintrc.js 文件

// ESLint 配置文件遵循 commonJS 的导出规则，所导出的对象就是 ESLint 的配置对象
// 文档：https://eslint.bootcss.com/docs/user-guide/configuring
module.exports = {
  // 示意当前目录即为根目录，ESLint 规定将被限度到该目录下
  root: true,
  // env 示意启用 ESLint 检测的环境
  env: {
    // 在 node 环境下启动 ESLint 检测
    node: true
  },
  // ESLint 中根底配置须要继承的配置
  extends: ["plugin:vue/vue3-essential", "@vue/standard"],
  // 解析器
  parserOptions: {parser: "babel-eslint"},
  // 须要批改的启用规定及其各自的谬误级别
  /**
   * 谬误级别分为三种：* "off" 或 0 - 敞开规定
   * "warn" 或 1 - 开启规定，应用正告级别的谬误：warn (不会导致程序退出)
   * "error" 或 2 - 开启规定，应用谬误级别的谬误：error (当被触发的时候，程序会退出)
   */
  rules: {
    "no-console": process.env.NODE_ENV === "production" ? "warn" : "off",
    "no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off"
  }
};

那么到这里咱们曾经大抵的理解了.eslintrc.js 文件，基于 ESLint 如果咱们呈现不符合规范的代码格局时，那么就会失去一个对应的谬误。

比方：

咱们能够把 Home.vue 中的 name 属性值，由单引号改为双引号

这个谬误示意：

此时咱们触发了一个《谬误级别的谬误》
触发该谬误的地位是在 Home.vue 的第 13 行第九列中
谬误形容为：字符串必须应用单引号
谬误规定为：quotes

那么想要解决这个谬误，通常状况下咱们有两种形式：

依照 ESLint 的要求批改代码
批改 ESLint 的验证规定

依照 ESLint 的要求批改代码：

在 Home.vue 的第 13 行中把双引号改为单引号

批改 ESLint 的验证规定：

在 .eslintrc.js 文件中，新增一条验证规定
```
"quotes": "error" // 默认
"quotes": "warn" // 批改为正告
"quotes": "off" // 批改不校验
```
然而一个团队中，人员的程度高下不齐，大量的 ESLint 规定校验，会让很多的开发者头疼不已，从而大大影响了我的项目的开发进度。

试想一下，在你去实现我的项目代码的同时，还须要时时刻刻留神代码的格局问题，这将是一件如许苦楚的事件！

那么有没有什么方法，既能够保障 ESLint 规定校验，又能够解决严苛的格局规定导致的影响我的项目进度的问题呢？

请看下一节《标准化编程标准解决方案之Prettier》

正文完