前端代码格式化初探
什么是代码风格
这个问题是最基础的，也是最重要的。只有理解了这个问题，下面的问题才有意义。代码风格可以类比于写作风格，只不过写作风格更加丰富多彩。例如美学家朱光潜的文字朴实直接，却很容易让人产生共情。两年前我第一次读他的《给青年的十二封信》，就引起了很多的思考。那种良师的谆谆教导的感觉，至今都让我难以忘记。类似英语环境中的作家海明威，就是行文硬朗，人送称号——美国硬汉。这就是一种写作风格。代码风格就更加具体了，好比句尾加不加分号，函数加不加空格，函数注释的格式。这些细碎的东西就构成了代码的风格。风格没有好坏，只有适不适合。它的目的就是让代码更加容易理解，要知道代码是写给人看的，附带着能在机器上运行。
为什么保持代码风格的统一
答案是在多人协作开发中，保证良好的、连续的阅读体验，减少代码的歧异性，让后续开发者能够高效，快速继续开发。换句话说，看别人写的作文。字迹清晰，干净整洁的文章，看着就让人心情舒畅，更加愿意继续去阅读。
通过什么方式保持统一的风格
既然要保持代码风格的统一，那就需要一份标准的代码风格规定，它是需要人为去讨论制定的。那么有了标准之后，由谁来核实是否执行了这份标准呢？又如何执行标准呢？
如果从拟人化的角度来思考这两个问题，我们需要一个「标准执行委员会」来贯彻代码风格标准的执行。而在计算机的世界中，这个委员会的角色则是由一个单独的程序担任——ESlint。我们更习惯叫这个程序为插件。
还记得初始化一个 Vue 新项目的时候，会出现一些默认插件安装的提示，其中一个就是 ESlint。如果你选择安装了这个插件，那么当你 npm run dev 运行项目的时候，IDE 会运行 ESlint 插件检查你的代码是否符合 ESlint 规范。如果不符合，那么就会在控制台报一系列的warning。这也表明你的项目具备了基础的代码风格检验功能。
ESlint的双重面孔
欧拉欧拉欧拉，出来吧，我的替身使者！
我们通常说使用 Eslint 来规范化代码，其实这里的 ESlint 有着两幅面孔。如果不区分它们的话，一些描述会很容易搞混我们的大脑。首先它的第一重面孔就是项目初始化安装的 ESlint 插件，它是在项目初始化时安装的。也可以在新建项目之后，通过npm i 安装依赖的方式进行安装。它的目的就是在运行项目或者打包项目时，检查项目代码是否符合制定的风格标准。这也意味着两个事情：
1.它需要一份关于代码风格标准的描述文件。
2.它只能在项目最终运行时才能知道代码是否符合风格标准。
第一个问题的解决方案就是项目根目录下面的 .eslintrc.js 文件，这份文件规定关于代码风格标准的具体情况。Eslint 插件会去读取这份文件来比较项目代码风格是否符合，不符合的报出 warning 或者其他提醒。而第二个问题的解决就需要 IDE 的参与了，这也就是 ESLint的第二幅面孔的诞生，那就是 VSCode 的插件模式。
VSCode 作为微软下面主力推行的集成开发工具，免费是它的一个特点，另一个特点就是插件模式。其中常用的 ESlint 插件就可以解决第二个问题。当你安装了 ESlint 插件之后，它会根据你的 .eslintrc.js，实时检验你的代码的规范性。如果不符合规范，会在相应位置处出现红色波浪线标注。它将运行时被动校验转变为 code 时的主动校验，提前将不规范扼杀在摇篮里。
Prettier 和 ESlint 的关系
它们的关系是相互依存的，ESlint 是检错，Prettier 是纠错的。检错读取配置的 .eslintrc.js 文件检验代码的格式是否符合配置，不符合报错/报警告。但是它不知道如何修复错误的地方。例如，你配置每行代码开头缩进4个空格，那么当你只缩进了2个空格的时候，ESlint检查出来说你不符合规范。但是，它不能将你错误的格式修正为正确的。这不是它的职责范围。
这就需要一个纠错工具。这个工具需要对代码进行格式化的处理，也就是 Prettier 做的事情—让代码更加漂亮点。
一般为了早期处理问题，都是在保存文件时自动运行 Prettier 对当前修改文件的代码进行格式化。因为检错和纠错的工具不是一个东西，那么难免会出现冲突的地方。所以又有个新闻，就是解决 Prettier 和 ESLint 之间的冲突情况。