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

38次阅读

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

为什么须要编程标准?

工欲善其事,必先利其器

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

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

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

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

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

有的中央有分号,有的中央没有分号

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

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

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

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

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

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

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

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

那怎么办呢?

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

答案是:能够的!

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

  1. 编码标准
  2. git 标准

两大类

编程标准一:代码检测工具 ESLint

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

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

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

首先 ESLint2013 年 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 属性值,由单引号改为双引号

这个谬误示意:

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

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

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

依照 ESLint 的要求批改代码:

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

批改 ESLint 的验证规定:

  1. .eslintrc.js 文件中,新增一条验证规定

    "quotes": "error" // 默认
    "quotes": "warn" // 批改为正告
    "quotes": "off" // 批改不校验

    然而一个团队中,人员的程度高下不齐,大量的 ESLint 规定校验,会让很多的开发者头疼不已,从而大大影响了我的项目的开发进度。

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

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

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

正文完
 0