为什么须要编程标准?
工欲善其事,必先利其器
对于大型的企业级我的项目而言,通常状况下咱们都是一个团队很多人来独特进行开发的。而又因为团队人员对技术了解上的参差不齐,所以就会导致呈现一种状况,那就是《一个我的项目无奈具备对立的编程标准,导致我的项目的代码像多个不同材质的补丁拼接起来一样》
构想一下,上面的这段代码有一个团队进行开发,因为没有具备对立的代码规范,所以生成了上面的代码:
这段代码能够失常运行没有问题,然而整体的代码构造却十分的难看。
有的中央有空格进行宰割,有的中央却没有
有的中央是单引号,有的中央却是双引号
有的中央有分号,有的中央没有分号
….
这样的我的项目尽管能够失常运行,然而如果把它放到大厂的我的项目中,的确 不及格 的,它会被认为是 不可保护、不可扩大的代码内容
那么所谓的大厂规范的代码构造应该是什么样子的呢?
咱们把下面的代码进行一下修改,做一个比照:
批改之后的代码具备了对立的标准之后,是不是看起来就难受多了!
并且以上所列举进去的只是《编程标准》中的一小部分内容!
那么有些同学可能就会说了,你列举进去这些编程标准有什么用啊!
哪怕你写上一部书,咱们一个团队这么多人,总不能指望所有人都看一遍,并且严格的恪守你所说的标准吧!
说的没错!指望人被动的恪守这些标准不太事实
那怎么办呢?
那么咱们可不可以另辟蹊径,让程序主动解决规范化的内容呢?
答案是:能够的!
本系列中我会为大家分享,如何自动化的对代码进行标准,其中次要包含:
- 编码标准
- git 标准
两大类
编程标准一:代码检测工具 ESLint
在咱们去创立我的项目的时候,脚手架工具曾经帮忙咱们装置了 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
》