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"
  }
}

precommitprepush 你需要根据自己的情况选择一个,无需两个都设置。

results matching ""

    No results matching ""