关于javascript:前端架构师神技三招统一代码风格一文讲透

本文从代码标准，代码查看，代码格式化，以及编辑器自动化实现的方向，介绍代码标准对立在咱们团队的实际利用。

纲要预览

本文介绍的内容包含以下方面：

• 意识代码标准
• 制订和对立标准
• 神技一：ESLint
• 神技二：Prettier
• 神技三：VSCode
• 附录：命名和我的项目构造标准

意识代码标准

先来思考两个问题：

1. 什么是代码标准？
2. 为什么须要代码标准？

如果你是一个经验丰富的前端开发，你肯定接触过这样的老我的项目：变量名是 abc，fds 这种随便起的，或者是 name1, name2 这种带数字起名，这样的变量不加正文，鬼都不晓得它是干什么的。

这类代码就是一种典型的不标准代码。这样的代码除了让咱们开发人员情绪火暴，最重要的问题是，它极大的升高了团队合作的效率和程序品质。

在团队合作过程中，当组内其他人须要应用或 review 你的代码，看到这种状况，除了喷你，还要破费大量工夫理解你写的是什么。同时这样非常容易造成变量抵触，带来未知隐患，调试艰难等问题，甚至能够看出一个程序员的编码态度和业余水平。

当然，代码标准蕴含很多方面，变量命名标准只是最根底的标准。不标准的中央越多，程序品质越低，团队合作的效率也就会越低。

理解了不标准的代码以及不标准代码带来的问题，作为前端架构师，咱们就要思考三个问题：

1. 如何制订标准？
2. 如何对立团队的标准？
3. 如何检测标准？

制订和对立标准

像下面给变量随便乱起名字的状况，在晚期的前端我的项目中十分常见。

因为晚期我的项目规模，团队规模无限，没有命名标准这种意识，随便起名貌似也没有太大的问题，只有不反复就好。然而随着前端我的项目规模越来越大，复杂度越来越高，不标准带来的问题越来越多，这种标准意识才缓缓的被器重起来。

通过社区的一直倒退，协定了命名蕴含以下几种标准：

• 下划线命名：user_name
• 中划线命名：user-name
• 小驼峰命名：userName
• 大驼峰命名：UserName

有了这些标准，开发者们起名字的时候心里就有谱了。而且这些标准目前也被大多数开发者们承受，如果不依照标准命名，很可能会被共事吐槽喽！

当标准成为广泛共识之后，大家依照本人的爱好应用不同的标准，逐步造成了本人的编码习惯。在一个团队中，每个开发者往往各自有各自的编码习惯。

然而这又成为了问题。再拿变量举例：一个团队中，有的人习惯用下划线命名变量，如 user_name；有的人习惯用驼峰命名变量，如 userName。这两种命名形式都正确，都符合规范，然而会造成团队的代码格调凌乱，无奈对立。

那为什么要对立呢？

对立的益处有很多。比方咱们对立规定：命名变量用下划线，命名办法用小驼峰。那么在团队合作时，大家看到下划线就晓得这是一个变量，看到小驼峰就晓得这是一个办法。十个人的代码写进去是一个人的格调，不须要理解其余的编码格调，实现无障碍合作。

十个人的代码写出一个人的格调，说起来很现实，然而靠监督和盲目实现简直是不可能的。

怎么办呢？上面就是本文重点：祭出实现代码标准的三招神技。

神技一：ESLint

下面说到，团队合作开发我的项目，因为每个人的编码习惯不同，会写出各种各样的代码。这样的代码又乱又难以保护。

所以咱们心愿有这样一个工具，能够制订一套比拟残缺全面的标准，如果大家的编码不符合规范，程序就会正告甚至报错，用这种工具来倒逼团队成员恪守对立的代码格调。

这个工具是有的，咱们都听过，就是赫赫有名的 ESLint

ESLint 有两种能力：

• 查看代码品质，如是否有已定义但未应用的变量。
• 查看代码格调，换行，引号，缩进等相干的标准。

这两种能力简直涵盖了绝大部分代码标准，并且具体标准是可配置的，团队能够定制本人喜爱的代码格调。

定制标准后，我的项目运行或热更新时，ESLint 就会主动查看代码是否符合规范。

问：ESLint 查看与 TypeScript 查看有啥区别？

TypeScript 只会查看 类型谬误 ，而 ESLint 会查看 格调谬误。

尝试 ESLint

首先在我的项目下装置：

$ npm install eslint --save-dev

而后运行命令初始化配置：eslint --init

eslint 是一个交互式命令，能够高低切换抉择适宜我的项目的选项；实现会生成 .eslintrc.json 文件。

根本配置

.eslintrc.json 的根本配置如下：

{
  "env": {
    "browser": true,
    "es2021": true,
  },
  "extends": ["eslint:recommended"],
  "parserOptions": {
    "ecmaVersion": 12,
    "sourceType": "module",
  },
  "rules": {},};

这个根本配置蕴含了一套默认举荐的配置，定义在 eslint:recommended 这个扩大中。

React 配置

React 在默认配置的根底上，也有一套举荐的语法配置，定义在 plugin:react/recommended 这个插件中，如果你的前端框架是 React，要定义 eslint 标准，那么在根本配置上增加上面标记 + 号的配置即可：

{
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": [
    "eslint:recommended",
+   "plugin:react/recommended"
  ],
  "parserOptions": {
+   "ecmaFeatures": {
+     "jsx": true
+   },
    "ecmaVersion": 12,
    "sourceType": "module"
  },
+ "plugins": [
+   "react"
+ ],
  "rules": {}};

React + TS 配置

若要 React 反对 TS，还要加一些额定配置：

{
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended"
+   "plugin:@typescript-eslint/recommended"
  ],
+ "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaFeatures": {"jsx": true},
    "ecmaVersion": 12,
    "sourceType": "module"
  },
  "plugins": [
    "react",
+   "@typescript-eslint"
  ],
  "rules": {}};

代码查看

下面定义好标准之后，咱们当初来写一段代码，并执行标准查看。

新建 index.js 文件，写入内容：

const a = '13'
function add() {return '1'}

从 js 角度讲，这两行代码是没问题的。而后咱们运行查看命令：

$ npx eslint index.js

这时会在控制台看到报错：

2:7   error  'a' is assigned a value but never used  no-unused-vars
4:10  error  'add' is defined but never used         no-unused-vars

2 problems (2 errors, 0 warnings)

谬误的意思是变量 a 和函数 add 已申明但未应用，阐明代码不合乎约定的标准。这种异样也很常见，在脚手架构建的我的项目中应用 npm run dev 和 npm start 时就会执行下面的查看命令。

ESLint 标准

下面说过，ESLint 能够自定义查看标准，标准定义在 .eslintrc.json 配置文件的 rules 对象下。

比方，定义标准，字符串必须应用双引号：

{
  "rules": {"quotes": ["error", "double"]
  }
}

定义好之后，如果你的代码中字符串应用单引号，ESLint 就会报错。

quotes 示意引号标准，是泛滥标准中的一个，它的值是一个数组。

数组第一项是谬误级别，是以下 3 个值之一：

• "off" or 0 – 敞开标准
• "warn" or 1 – 正告级别标准
• "error" or 2 – 谬误级别标准

数组第二项才是真正的标准，具体残缺的标准参考 这里

关上下面的网页，打绿钩的示意是已配置的。须要自定义间接写在 rules 里即可。

神技二：Prettier

上一步咱们用 ESLint 实现了标准的制订和查看。当开发人员实现一段代码保留时，我的项目会主动执行 eslint 查看命令查看代码，查看到异样后输入的控制台，待开发人员修复异样后能力持续开发。

如果你配置的编码标准比较复杂和严格，比方字符串必须单引号，代码结尾必须用分号，换行必须是 2 个 tab 且不能够用空格。像这种很细的标准，大家开发过程中难免会有不合乎，这个时候控制台就会频繁报错，开发人员就会频繁修复一个空格一个标点符号，工夫久了异样烦人。

正因为如此，在脚手架生成的我的项目中尽管默认都开启了 ESLint，然而很多人应用不久后感觉烦人，效率低下，所以都手动敞开了 ESLint。

那么，有没有更高效的办法，让大家十分快捷的写出齐全符合规范的代码呢？

有，它便是第二招神技：Prettier

Prettier 是以后最风行的代码格式化工具，它最次要的作用就是格式化代码。

什么是格式化？下面咱们用 ESLint 定制了编码标准，当检测到不标准的代码，提醒异样，而后须要咱们开发人员依照提醒手动修复不标准的中央。

而格式化的威力，是将不标准的代码，依照标准 一键主动修复。

听起来很振奋人心，咱们来试一下。

首先在我的项目下装置：

$ npm install prettier --save-dev

而后新建 .prettierrc.json 文件：

{
  "singleQuote": true,
  "semi": true
}

这个配置文件和下面 ESLint 下的 rules 配置作用统一，就是定义代码标准 ——— 没错，Prettier 也反对定义标准，而后依据标准格式化代码。

列一下 Prettier 的罕用标准配置：

{
  "singleQuote": true, // 是否单引号
  "semi": false, // 申明结尾应用分号(默认 true)
  "printWidth": 100, // 一行的字符数，超过会换行（默认 80）"tabWidth": 2, // 每个 tab 相当于多少个空格（默认 2）"useTabs": true, // 是否应用 tab 进行缩进（默认 false）"trailingComma": "all", // 多行应用拖尾逗号（默认 none）"bracketSpacing": true, // 对象字面量的大括号间应用空格（默认 true）"jsxBracketSameLine": false, // 多行 JSX 中的 > 搁置在最初一行的结尾，而不是另起一行（默认 false）"arrowParens": "avoid" // 只有一个参数的箭头函数的参数是否带圆括号（默认 avoid）}

定义好配置后，咱们在 index.js 文件中写入内容：

const a = "13"
function add() {return "1"}

而后在终端运行格式化命令：

$ npx prettier --write index.js

格式化之后，再看 index.js 文件变成了这样：

const a = '13';
function add() {return '1';}

看到变动了吧，双引号主动变成了单引号，行结尾主动加了分号，刚好与配置文件中定义的标准统一。

喜大普奔！终于不必再手动修复不标准的代码了，一个命令就能搞定！

下面是格式化一个文件，当然也反对批量格式化文件。批量格式化通过含糊匹配查找文件，比拟罕用，倡议定义在 script 脚本中，如下：

// package.json
"scripts": {"format": "prettier --write \"src/**/*.js\"\"src/**/*.ts\"",}

Prettier 还反对针对不同后缀的文件设置不同的代码标准，如下：

{
  "semi": false,
  "overrides": [
    {
      "files": "*.test.js",
      "options": {"semi": true}
    },
    {"files": ["*.json"],
      "options": {"parser": "json-stringify"}
    }
  ]
}

问：ESLint 与 Prettier 有啥区别？

相同点：都能够定义一套代码标准。

不同点：ESLint 会在查看时对不标准的代码提醒谬误；而 Prettier 会间接依照标准格式化代码。

所以，ESLint 和 Prettier 定义的标准要统一，不能抵触。

神技三：VSCode

下面，咱们通过 ESLint 和 Prettier 两招神技，实现了代码标准制订，代码标准查看，以及依据标准一个命令格式化代码，使得对立团队代码格调变的非常容易。

然而，冲破效率的挑战是没有极限的。这时候又有小伙伴发声了：尽管是容易了，然而查看代码还是得依赖查看命令，格式化代码也得依赖格式化命令，这样总显得不够优雅。

好吧，不够优雅，那还有优雅的解决方案吗？

答案是有。它就是咱们的第三招神技 —— VSCode

弱小的插件

VSCode 对咱们前端来说都不生疏，是咱们日日相伴的开发武器。以后 VSCode 简直对立了前端圈的编辑器，功能强大，倍受好评。

既然能失去如此宽泛的认可，那么就必然有它的优越性。VSCode 除了轻量启动速度快，最弱小的是其丰盛多样的插件，能满足不必使用者各种各样的需要。

在泛滥插件中，ESLint 就是十分弱小的一个。没错，这个插件就是咱们后面说到的神技第一招 ESLint 在 VSCode 上反对的同名插件。截图如下：

装置了这个插件之后，之前须要在终端执行 eslint 命令能力查看进去的异样，当初间接标记在你的代码上了！

即便是你敲错了一个符号，该插件也会实时的追踪到你谬误的中央，而后给出标记和异样揭示。这几乎大大晋升了开发效率，再也不必执行命令来查看代码了，看谁还说不优雅。

既然编辑器有 ESLint 插件，那是不是也有 Prettier 插件呢？猜对了，当然有插件，插件全名叫 Prettier - Code formatter，截图如下，在 VSCode 中搜寻装置即可。

Prettier 插件装置之后会作为编辑器的一个格式化程序。在代码中右键格式化，就能够抉择 Prettier 来格式化以后代码。

如果要想 Prettier 实现自动化，则还须要在编辑器中配置。

编辑器配置

VSCode 中有一个用户设置 setting.json 文件，其中保留了用户对编辑器的自定义配置。

这个配置十分丰盛，详见官网。首先咱们在这个配置当中将 Prettier 设置为默认格式化程序：

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "": {"editor.defaultFormatter":"esbenp.prettier-vscode"}
}

设置好这一步之后，重点来了！ 咱们再来配置保留文件主动格式化：

{"editor.formatOnSave": true}

配好之后，神奇的事件产生了：当你写完代码保留的时候，发现你正在编辑的文件立即被格式化了。也就是说，无论你的代码按不依照标准写，保留的时候主动帮你格式化成标准的代码。

这一步其实是保留文件的时候主动执行了格式化命令。因为咱们下面配置了默认格式化程序为 Prettier，当初又配了保留时格式化，相当于将文件保留和 prettier 命令连贯了起来。

到这一步，在三大神技的加持之下，咱们曾经实现了代码的主动查看与主动格式化，当初你编码的时候不须要思考什么格局标准的问题，只有失常保留，编辑器会主动帮你做好这些事件。

共享编辑器配置

下面咱们在编辑器通过一顿配置，终于实现了主动格式化。当初咱们要把这些设置同步给团队内的其余成员，该怎么办，难道要一个一个再配一遍？

别慌，不必这么麻烦。VSCode 的设置分为两类：

• 用户设置：利用于整个编辑器
• 工作区设置：利用于当前目录 / 工作区

这两类的配置内容是截然不同的，区别只是优先级的问题。如果你关上的我的项目目录蕴含工作区设置，那么这个工作区设置会笼罩掉以后的用户设置。

所以要想将设置同步给团队内的其余成员，咱们不须要去改变用户设置，只须要在我的项目目录下新建一个工作区设置即可。

增加工作区设置办法：在我的项目根目录下新建 .vscode/setting.json 文件，在这里写须要对立的编辑器配置。所以咱们把下面的 Prettier 配置写在这里即可实现共享。

附录：命名和我的项目构造标准

下面介绍了代码标准，代码检查和代码格式化，对立代码格调曾经很全面了。

在团队开发过程当中，咱们也积攒了一些并不会写在配置文件里的标准，这些标准在一个团队当中也是十分重要。这部分算是咱们的团队标准的分享吧。

次要说两局部：命名标准和我的项目构造标准。

命名标准

命名标准，文章结尾也说了，变量的四种命名标准。然而什么中央用哪种标准，咱们也是有约定的。

• 变量命名：下划线 user_id
• CSS-Class 命名：中划线 user-id
• 办法函数命名：小驼峰 userId
• JS-Class 命名：大驼峰 UserId
• 文件夹命名：中划线 user-id
• 文件夹下组件命名：中划线 user-id
• 组件导出命名：大驼峰 UserId

我的项目构造标准

我的项目构造标准次要是指 src 文件夹下的构造组织。

|-- src
    |-- index.tsx # 入口文件
    |-- assets # 动态资源目录
    |-- components # 公共组件目录
    |   |-- header
    |   |   |-- index.tsx
    |   |   |-- index.less
    |-- stores # 状态治理目录，与 pages 构造对应
    |   |-- admins
    |   |   |-- index.tsx # 状态文件
    |   |   |-- types.ts  # 定义状态类型
    |   |-- index.tsx
    |-- pages # 页面目录，与 stores 构造对应
    |   |-- admins
    |   |   |-- index.tsx
    |   |   |-- index.less
    |-- request
    |   |-- index.ts # axios 实例，全局申请解决
    |-- router
    |   |-- home.tsx
    |   |-- index.tsx
    |   |-- root.tsx
    |-- styles # 全局款式
    |   |-- common.less
    |   |-- index.less
    |-- utils # 工具目录
        |-- index.ts

往期精彩

本专栏会长期输入前端工程与架构方向的文章，已公布如下：

• 前端架构师的 git 功力，你有几成火候？
• 纯 Git 实现前端 CI/CD

如果喜爱我的文章，请点赞反对我吧！也欢送关注我的专栏，感激🙏🙏