3-16 检查代码

当项目代码变得日益庞大复杂时，如何保障代码质量？如何保障多人协助开发时代码的可读性？

完全解决以上问题不是一个简单的事，但做检查代码能解决大部分问题。本节将教你如何结合构建做代码检查。

代码检查具体是做什么

检查代码和 Code Review 很相似，都是去审视提交的代码可能存在的问题。 但 Code Review 一般通过人去执行，而检查代码是通过机器去执行一些自动化的检查。 自动化的检查代码成本更低，实施代价更小。

检查代码主要检查以下几项：

• 代码风格：让项目成员强制遵守统一的代码风格，例如如何缩紧、如何写注释等，保障代码可读性，不把时间浪费在争论如何写代码更好看上；
• 潜在问题：分析出代码在运行过程中可能出现的潜在 Bug。

其中检查代码风格相关的工具很多也很成熟，分析潜在问题的检查由于情况复杂目前还没有成熟的工具。

目前已经有成熟的工具可以检验诸如 JavaScript、TypeScript、CSS、SCSS 等常用语言。

怎么做代码检查

在做代码风格检查时需要按照不同的文件类型来检查，下面来分别介绍。

检查 JavaScript

目前最常用的 JavaScript 检查工具是 ESlint ，它不仅内置了大量常用的检查规则，还可以通过插件机制做到灵活扩展。

ESlint 的使用很简单，在通过

npm i -g eslint

按照到全局后，再在项目目录下执行

eslint init

来新建一个 ESlint 配置文件 .eslintrc，该文件格式为 JSON。

如果你想覆盖默认的检查规则，或者想加入新的检查规则，你需要修改该文件，例如使用以下配置：

{
    // 从 eslint:recommended 中继承所有检查规则
    "extends": "eslint:recommended",
    // 再自定义一些规则     
    "rules": {
        // 需要在每行结尾加 ;        
        "semi": ["error", "always"],
        // 需要使用 "" 包裹字符串         
        "quotes": ["error", "double"]
    }
}

写好配置文件后，再执行

eslint yourfile.js

去检查 yourfile.js 文件，如果你的文件没有通过检查，ESlint 会输出错误原因，例如：

/yourfile.js
   296:13  error  Strings must use doublequote  quotes
   298:7   error  Missing semicolon             semi

✖ 2 problems (2 errors, 0 warnings)

ESlint 还有很多功能和检查规则，由于篇幅有限这里就不详细介绍，可以去其官网阅读文档。

检查 TypeScript

TSLint 是一个和 ESlint 相似的 TypeScript 代码检查工具，区别在于 TSLint 只专注于检查 TypeScript 代码。

TSLint 和 ESlint 的使用方法很相似，首先通过

npm i -g tslint

按照到全局，再去项目根目录下执行

tslint --init

生成配置文件 tslint.json，在配置好后，再执行

tslint yourfile.ts

去检查 yourfile.ts 文件。

检查 CSS

stylelint 是目前最成熟的 CSS 检查工具，内置了大量检查规则的同时也提供插件机制让用户自定义扩展。 stylelint 基于 PostCSS，能检查任何 PostCSS 能解析的代码，诸如 SCSS、Less 等。

首先通过

npm i -g stylelint

按照到全局后，去项目根目录下新建 .stylelintrc 配置文件， 该配置文件格式为 JSON，其格式和 ESLint 的配置相似，例如：

{
  // 继承 stylelint-config-standard 中的所有检查规则
  "extends": "stylelint-config-standard",
  // 再自定义检查规则  
  "rules": {
    "at-rule-empty-line-before": null
  }
}

配置好后，再执行

stylelint "yourfile.css"

去检查 yourfile.css 文件。

stylelint 还有很多功能和配置项没有介绍到，可以访问其官方进一步了解。

目前很多编辑器，例如 Webstorm、VSCode 等，已经集成了以上介绍过的检查工具，编辑器会实时地把检查工具输出的错误显示编辑的源码上。 通过编辑器集成后，你不用通过命令行的方式去定位错误。

结合 Webpack 检查代码

以上介绍的代码检查工具可以和 Webpack 结合起来，在开发过程中通过 Webpack 输出实时的检查结果。

结合 ESLint

eslint-loader 可以方便的把 ESLint 整合到 Webpack 中，使用方法如下：

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        // node_modules 目录的下的代码不用检查
        exclude: /node_modules/,
        loader: 'eslint-loader',
        // 把 eslint-loader 的执行顺序放到最前面，防止其它 Loader 把处理后的代码交给 eslint-loader 去检查
        enforce: 'pre',
      },
    ],
  },
}

接入 eslint-loader 后就能在控制台中看到 ESLint 输出的错误日志了。

结合 TSLint

tslint-loader 是一个和 eslint-loader 相似的 Webpack Loader， 能方便的把 TSLint 整合到 Webpack，其使用方法如下：

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        // node_modules 目录的下的代码不用检查
        exclude: /node_modules/,
        loader: 'tslint-loader',
        // 把 tslint-loader 的执行顺序放到最前面，防止其它 Loader 把处理后的代码交给 tslint-loader 去检查
        enforce: 'pre',
      },
    ],
  },
}

结合 stylelint

StyleLintPlugin 能把 stylelint 整合到 Webpack，其使用方法很简单，如下：

const StyleLintPlugin = require('stylelint-webpack-plugin');

module.exports = {
  // ...
  plugins: [
    new StyleLintPlugin(),
  ],
}

一些建议

把代码检查功能整合到 Webpack 中会导致以下问题：

• 由于执行检查步骤计算量大，整合到 Webpack 中会导致构建变慢；
• 在整合代码检查到 Webpack 后，输出的错误信息是通过行号来定位错误的，没有编辑器集成显示错误直观；

为了避免以上问题，还可以这样做：

• 使用集成了代码检查功能的编辑器，让编辑器实时直观地显示错误；
• 把代码检查步骤放到代码提交时，也就是说在代码提交前去调用以上检查工具去检查代码，只有在检查都通过时才提交代码，这样就能保证提交到仓库的代码都是通过了检查的。

如果你的项目是使用 Git 管理，Git 提供了 Hook 功能能做到在提交代码前触发执行脚本。

husky 可以方便快速地为项目接入 Git Hook， 执行

npm i -D husky

安装 husky 时，husky 会通过 Npm Script Hook 自动配置好 Git Hook，你需要做的只是在 package.json文件中定义几个脚本，方法如下：

{
  "scripts": {
    // 在执行 git commit 前会执行的脚本  
    "precommit": "npm run lint",
    // 在执行 git push 前会执行的脚本  
    "prepush": "lint",
    // 调用 eslint、stylelint 等工具检查代码
    "lint": "eslint && stylelint"
  }
}

precommit 和 prepush 你需要根据自己的情况选择一个，无需两个都设置。