【开发工具】前端代码格式化初探

1,487 阅读6分钟

前言


  本篇文章确切的标题应该是:“在 VSCode 中使用 ESlint 和 Prettier 进行代码格式化”。笔者是入行两年多一点的菜鸟,一些知识点的了解和工具🔧的使用一直都是流于浅显的层次上,不愿意也懒得去深究背后藏起来的知识树。但是现实经历告诉我,这一切是错误的。偷得了一时的小懒,还是偷不了日后的大懒。换句话说,深究知识诞生的背景及其缘由,更有助于内化吸收知识,进而不必花额外的经历去记忆它。因为它已经成为了你的一部分,自然而然的就能运用。

  举个例子,在写这篇文章之前,我老是记不住插件 Prettier 的拼写,心里觉得这个单词好特么奇怪呀,一点也不词不达意。但是,就在刚才,我突然发现这个单词不就是 pretty 的派生而来的嘛!pretty意思是漂亮的,派生出来的prettier就具有了人格化的含义,意味着能够使别人变得漂亮的人。这个别人就是指的我们写的代码。而且在英语语境中,也真正做到了词中有意。这样捋下来,这个单词就很容易记住了。

  基于此,我也是希望能够将插件用于代码格式化的过程梳理清楚,才能真正地应用工具提高我们的开发效率。

什么是代码风格


  这个问题是最基础的,也是最重要的。只有理解了这个问题,下面的问题才有意义。代码风格可以类比于写作风格,只不过写作风格更加丰富多彩。例如美学家朱光潜的文字朴实直接,却很容易让人产生共情。两年前我第一次读他的《给青年的十二封信》,就引起了很多的思考。那种良师的谆谆教导的感觉,至今都让我难以忘记。类似英语环境中的作家海明威,就是行文硬朗,人送称号——美国硬汉。这就是一种写作风格。代码风格就更加具体了,好比句尾加不加分号,函数加不加空格,函数注释的格式。这些细碎的东西就构成了代码的风格。风格没有好坏,只有适不适合。它的目的就是让代码更加容易理解,要知道代码是写给人看的,附带着能在机器上运行。

为什么保持代码风格的统一


  答案是在多人协作开发中,保证良好的、连续的阅读体验,减少代码的歧异性,让后续开发者能够高效,快速继续开发。换句话说,看别人写的作文。字迹清晰,干净整洁的文章,看着就让人心情舒畅,更加愿意继续去阅读。

通过什么方式保持统一的风格


  既然要保持代码风格的统一,那就需要一份标准的代码风格规定,它是需要人为去讨论制定的。那么有了标准之后,由谁来核实是否执行了这份标准呢?又如何执行标准呢?

  如果从拟人化的角度来思考这两个问题,我们需要一个「标准执行委员会」来贯彻代码风格标准的执行。而在计算机的世界中,这个委员会的角色则是由一个单独的程序担任——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 之间的冲突情况。

参考文章


www.cnblogs.com/mspeer/p/12…