携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第2天，点击查看活动详情
编程规范分析
为什么需要编程规范
在我们开发企业级的项目时，并不是一个人去开发的而是需要一个团队进行开发。而对于每个人来说，其书写习惯都不一样（这并没有什么错），但是这样就会出现一种情况，那就是由于项目没有一个统一的规范，导致项目的代码风格各异，就好像是布丁一样。
下面我们来看一个例子：
const product={
name: '商品',
price:10,
num: 5
};
let total =0;
function userTotal() {
total = total+1
}
userTotal()
从逻辑上讲这段代码没有任何问题，完全可以执行，但是整体上看起来却是非常的难看
原因很简单，那就是有的地方有空格，有的地方没有；有的地方有分号，有的地方没有，看起来并不是十分统一
如果单从代码运行方面来说，他是没问题的，但是要是要求严格一点的话，他就是不及格的，他会被认作是不可维护、不可扩展的代码内容
下边我们将他优化一下再来看一看
const product = {
name: '商品',
price: 10,
num: 5
}
let total =0;
function userTotal() {
total = total + 1
}
userTotal()
这样看着是不是就舒服多了
这时，可能有的小伙伴就说了，说这些有啥用，有谁会记得这么多的规范，就算你把它写成手册又有谁会一个字一个字的看
没错，指望着人去主动遵守这些东西根本不现实，那就没有办法了吗？不可能，万能的程序员有什么搞不定的，我们就让程序自己去规范
规范一：代码检测工具 ESLint
我相信大家一定都听说过 ESLint 的大名，他的目标非常简单，只有一个，那就是提供一个插件化的javascript 代码检测工具，说白了就是做代码格式检测的
我们可以在项目中创建一个 .eslintrc.js 文件，他就是 eslint 的配置文件
其配置文件中的内容大体包含以下这些
// 文档：https://eslint.bootcss.com/docs/user-guide/configuring
module.exports = {
// 选定根目录，ESLint 会限制该目录下的内容
// 表示当前目录即为根目录
root: true,
// env 表示启用 ESLint 检测的环境
env: {
// 在 node 环境下启动 ESLint 检测
node: true
},
// ESLint 中基础配置需要继承的配置
extends: [],
// 解析器
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"
}
}
当我们的项目中出现不符合规范的代码格式时，就会得到一个对应的错误
如果我们想解决这个错误，就需要按照 ESLint 的要求修改代码
说到这里，另一个问题又出现了，大量的 ESLint 校验规则，如果修改起来那会相当的头疼，还有可能影响项目进度
于是乎就引出了 Prettier 这个工具
欲知后事如何，且听下回分解
