前端工程化（1）

开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第13天，点击查看活动详情

代码规范

代码规范是指程序员在编码时要遵守的规则，规范的目的就是为了让程序员编写易于阅读、可维护的代码。

试想一下，一个几十万行代码的项目，存在几种不同的代码规范，阅读起来是什么感受？连代码缩进使用空格还是 Tab 都能引发不少程序员的争论，可以说统一代码规范是非常重要的事情。

统一代码规范除了刚才所说的两点外，还有其他好处：

• 规范的代码可以促进团队合作
• 规范的代码可以降低维护成本
• 规范的代码有助于 code review（代码审查）
• 养成代码规范的习惯，有助于程序员自身的成长

当团队的成员都严格按照代码规范来写代码时，可以保证每个人的代码看起来都像是一个人写的，看别人的代码就像是在看自己的代码（代码一致性），阅读起来更加顺畅。更重要的是我们能够认识到规范的重要性，并坚持规范的开发习惯。

#如何制订代码规范

代码规范一般包含了代码格式规范、变量和函数命名规范、文档注释规范等等。

#代码格式

一般是指代码缩进使用空格还是 Tab、每行结尾要不要加分号、左花括号需不需要换行等等。

#命名规范

命名规范一般指命名是使用驼峰式、匈牙利式还是帕斯卡式；用名词、名词组或动宾结构来命名。

const smallObject = {} // 驼峰式，首字母小写
const SmallObject = {} // 帕斯卡式，首字母大写
const strName = 'strName' // 匈牙利式，前缀表示了变量是什么。这个前缀 str 表示了是一个字符串

变量命名和函数命名的侧重点不同。

变量命名的重点是表明这个变量“是什么”，倾向于用名词命名。而函数命名的重点是表明这个函数“做什么”，倾向于用动宾结构来命名（动宾结构就是 doSomething）。

// 变量命名示例
const appleNum = 1
const sum = 10

// 函数命名示例
function formatDate() { ... }
function toArray() { ... }

由于拼音同音字太多，千万不要使用拼音来命名。

#文档注释

文档注释比较简单，例如单行注释使用 //，多行注释使用 /**/。

/**
 * 
 * @param {number} a 
 * @param {number} b 
 * @return {number}
 */
function add(a, b) {
    return a + b
}

// 单行注释
const active = true

如果要让团队从头开始制订一份代码规范，工作量会非常大，也不现实。所以强烈建议找一份比较好的开源代码规范，在此基础上结合团队的需求作个性化修改。

下面列举一些比较出名的 JavaScript 代码规范：

• airbnb (101k star 英文版) (opens new window)，airbnb-中文版(opens new window)
• standard (24.5k star) 中文版(opens new window)
• 百度前端编码规范 3.9k star(opens new window)

CSS 代码规范也有不少，例如：

• styleguide 2.3k star(opens new window)
• spec 3.9k star(opens new window)

#注释规范

有同学可能会听过这样一种说法：好的代码是不需要写注释的。其实这种说法有点片面。

如果你写的函数类似于以下这种：

function timestampToDate(timestamp = 0) {
    if (/\s/.test(timestamp)) {
        return timestamp
    }

    let date = new Date(timestamp)
    return date.toLocaleDateString().replace(///g, '-') + ' ' + date.toTimeString().split(' ')[0]
}

function objToUrlParam(obj = {}) {
    let param = ''
    for (let key in obj) {
        param += '&' + key + '=' + obj[key]
    }
    
    return param? '?' + param.substr(1) : ''
}

那不写注释很正常，代码逻辑简单，变量、函数命名完全契合代码逻辑。

但在工作中还有很多业务逻辑很复杂的需求，很有可能一个函数要写很多代码，再好的函数命名、变量命名也不一定能看懂代码逻辑。并且有些业务逻辑会跨多个模块，需要跟不同模块的函数打交道。

像这种复杂的代码，还有绕来绕去的业务逻辑，如果不写注释，分分钟变成传说中的“屎山”。

我们平时强调的代码规范、项目规范、重构等等，不就是为了减少沟通，提高开发效率吗。写注释的目的也是为了让代码更加容易理解，以后出问题了，也能快速定位问题，从而解决问题。

所以我觉得这个说法应该这样理解：不是不写注释，而是不写垃圾注释。

什么是垃圾注释？罗里吧嗦一大堆讲不到重要的就是垃圾注释，注释应该着重描述“做了什么”而不是“怎么做”。

function objToUrlParam(obj = {}) {
    let param = ''
    for (let key in obj) {
        param += '&' + key + '=' + obj[key]
    }
    
    return param? '?' + param.substr(1) : ''
}

例如上面这个函数，你可以这样写注释：“将对象转化为 URL 参数”。也可以这样写：“首先遍历对象，获取每一个键值对，将它们拼在一起，最后在前面补个问号，变成 URL 参数”。

第一个注释虽然描述做了什么，但对于这么简单的函数来说是不用注释的。第二个注释是垃圾注释的典型示例，描述了怎么做。

下面再看一个辣眼睛的：

public class Program  
{  
    static void Main(string[] args)  
    {  
        /* 这个程序是用来在屏幕上  
         * 循环打印1百万次”I Rule!”  
         * 每次输出一行。循环计数  
         * 从0开始，每次加1。  
         * 当计数器等于1百万时，  
         * 循环就会停止运行*/  
 
        for (int i = 0; i < 1000000; i++)  
        {  
            Console.WriteLine(“I Rule!”);  
        }  
    }  
}

总的来说，注释是必要的，并且要写好注释，着重描述代码做了什么。如果还有人说不写注释，让他看看 linux 项目去，每一个文件都有注释。

#如何检查代码规范

规范制订下来了，那怎么确保它被严格执行呢？目前有两个方法：

1. 使用工具校验代码格式。
2. 利用 code review 审查变量命名、注释。

建议使用这两个方法双管齐下，确保代码规范被严格执行。

下面让我们来看一下，如何使用工具来校验代码格式。

#ESLint

ESLint最初是由Nicholas C. Zakas 于2013年6月创建的开源项目。它的目标是提供一个插件化的javascript代码检测工具。

1. 下载依赖

// eslint-config-airbnb-base 使用 airbnb 代码规范
npm i -D babel-eslint eslint eslint-config-airbnb-base eslint-plugin-import

2. 配置 .eslintrc 文件

{
    "parserOptions": {
        "ecmaVersion": 2019
    },
    "env": {
        "es6": true,
    },
    "parser": "babel-eslint",
    "extends": "airbnb-base",
}

3. 在 package.json 的 scripts 加上这行代码 "lint": "eslint --ext .js test/ src/"。然后执行 npm run lint 即可开始验证代码。代码中的 test/ src/ 是要进行校验的代码目录，这里指明了要检查 test、src 目录下的代码。

不过这样检查代码效率太低，每次都得手动检查。并且报错了还得手动修改代码。

为了改善以上缺点，我们可以使用 VSCode。使用它并加上适当的配置可以在每次保存代码的时候，自动验证代码并进行格式化，省去了动手的麻烦（下一节讲如何使用 VSCode 自动格式化代码）。

#Stylelint

Stylelint 是一个开源的、用于检查 CSS 代码格式的开源工具。具体如何使用请看下一节。

#使用 VSCode 自动格式化代码

#格式化 JavaScript 代码

安装 VSCode，然后安装插件 ESLint。

选择 File -> Preference-> Settings（如果装了中文插件包应该是 文件 -> 选项 -> 设置），搜索 eslint，点击 Edit in setting.json。

将以下选项添加到配置文件

"editor.codeActionsOnSave": {
    "source.fixAll": true,
},
"eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact",
],
"eslint.alwaysShowStatus": true,
"stylelint.validate": [
    "css",
    "less",
    "postcss",
    "scss",
    "vue",
    "sass"
],

同时要确保 VSCode 右下角的状态栏 ESlint 是处于工作状态的。如果右下角看不到 Eslint 的标识，请按照上面讲过的步骤打开 setting.json，加上这行代码：

"eslint.alwaysShowStatus": true,

配置完之后，VSCode 会根据你当前项目下的 .eslintrc 文件的规则来验证和格式化代码。

#TypeScript

下载插件

npm install --save-dev typescript @typescript-eslint/parser @typescript-eslint/eslint-plugin

在 .eslintrc 配置文件，添加以下两个配置项：

"parser": "@typescript-eslint/parser",
"plugins": [
    "@typescript-eslint"
],

在根目录下的 package.json 文件的 scripts 选项里添加以下配置项：

"scripts": {
  "lint": "eslint --ext .js,.ts,.tsx test/ src/",
},

test/ src/ 是你要校验的目录。修改完后，现在 ts 文件也可以自动格式化了。

如果你使用 Vue-CLI 创建项目，并且想要格式化 TypeScript 的代码，则需要在 .eslintrc.js 文件添加或修改以下几项：

parser: 'vue-eslint-parser',
plugins: [
    '@typescript-eslint',
],
parserOptions: {
    parser: '@typescript-eslint/parser',
    ecmaVersion: 2020,
},

这样就可以格式化 .js .ts .vue 文件了。

#格式化 CSS 代码

下载依赖

npm install --save-dev stylelint stylelint-config-standard

在项目根目录下新建一个 .stylelintrc.js 文件，并输入以下内容：

module.exports = {
    extends: "stylelint-config-standard"
}

VSCode 添加 stylelint 插件：

然后就可以看到效果了。

如果你想修改插件的默认规则，可以看官方文档 (opens new window)，它提供了 170 项规则修改。例如我想要用 4 个空格作为缩进，可以这样配置：

module.exports = {
    "extends": "stylelint-config-standard",
    "rules": {
        "indentation": 4
    }
}

如果你想格式化 sass scss 文件，则需要下载 stylelint-scss stylelint-config-standard-scss 插件：

npm i -D stylelint-scss stylelint-config-standard-scss

注意，要把 stylelint-config-standard 改成 stylelint-config-standard-scss，然后就可以格式化 scss 文件了。

module.exports = {
    extends: "stylelint-config-standard-scss"
}

#扩展

如何格式化 HTML、Vue（或其他后缀） 文件中的 HTML 代码？

.vue 文件的 HTML 代码可以使用 eslint-plugin-vue 插件来进行格式化：

extends: [
    'plugin:vue/recommended', // 在 .eslintrc.js 文件中加上这一行代码
    '@vue/airbnb',
],

其他的 HTML 文件需要利用 VSCode 自带的格式化，快捷键是 shift + alt + f。假设当前 VSCode 已经打开了一个 HTML 文件，按下 shift + alt + f 会提示你选择一种格式化规范。如果没提示，那就是已经有默认的格式化规范了，然后 HTML 文件的所有代码都会格式化，并且格式化规则还可以自己配置。

#踩坑

#Unknown word (CssSyntaxError) 错误

这个问题主要是因为 stylelint 升级到 14 大版本造成的。

解决方案一

安装 stylelint 新的相关依赖：

npm i -D stylelint-config-recommended-vue stylelint-config-standard-scss postcss-html

然后修改 .stylelintrc.js 文件的配置项：

extends: [
    'stylelint-config-standard-scss', 
    'stylelint-config-recommended-vue',
    'stylelint-config-recommended-vue/scss',
],
customSyntax: 'postcss-html',

这样修改以后，就不会再报错了。

解决方案二

第二个解决方案就是将以上三个插件的版本降一个大版本就好了，最后的版本如下：

"stylelint": "^13.13.1",
"stylelint-config-standard": "^22.0.0",
"stylelint-scss": "^3.21.0",

同时需要将 VSCode 的 stylelint 插件降级，现在插件的最新版本是 1.0.3，不支持 stylelint 13 版本。点击插件旁边的小齿轮，再点 Install Another Version，选择其他版本进行安装。

选 0.87.6 版本安装就可以了，这时 css 自动格式化功能恢复正常。

#忽略 .vue 文件中的 HTML 模板验证规则无效

举个例子，如果你将 HTML 模板每行的代码文本长度设为 100，当超过这个长度后 eslint 将会报错。此时如果你还是想超过这个长度，可以选择忽略这个规则：

/* eslint-disable max-len */

注意，以上这行忽略验证的代码是不会生效的，因为这个注释是 JavaScript 注释，我们需要将注释改为 HTML 格式，这样忽略验证才会生效：

<!-- eslint-disable max-len -->

#Code Review 代码审查

代码审查是指让其他人来审查自己代码的一种行为。审查有多种方式：例如结对编程（一个人写，一个人看）或者统一某个时间点大家互相做审查（单人或多人）。

代码审查的目的是为了检查代码是否符合代码规范以及是否有错误，另外也能让评审人了解被审人所写的功能。经常互相审查，能让大家都能更清晰地了解整个项目的功能，这样就不会因为某个核心开发人员离职了而引起项目延期。

当然，代码审查也是有缺点的：一是代码审查非常耗时，二是有可能引发团队成员争吵。据我了解，目前国内很多开发团队都没有代码审查，包括很多大厂。

个人建议在找工作时，可以询问一下对方团队是否有测试规范、测试流程、代码审查等。如果同时拥有以上几点，说明是一个靠谱的团队，可以优先选择。