2.代码质量检查

代码质量检查

前端代码中的常见问题(Why Lint)

书写风格

这个问题不用作过多阐述，想必接手过他人代码的同学，多少都有些体会。简单来说，太过随意的代码会让强迫症患者难以容忍，难以阅读理解的代码有时甚至不如推倒重来。

// bad
var once
  , upon
  , aTime;
// good
var once,
    upon,
    aTime;
// bad
var hero = {
    firstName: 'Bob'
  , lastName: 'Parr'
  , heroName: 'Mr. Incredible'
  , superPower: 'strength'
};
// good
var hero = {
  firstName: 'Bob',
  lastName: 'Parr',
  heroName: 'Mr. Incredible',
  superPower: 'strength'
};

代码规范

什么样的代码是低质量或高质量的？好的代码可能会让你如读小说一般被吸引，糟糕的代码会让你看一眼就不想继续、甚至看半天而不知所云。

有人可能认为初级程序员才会有这种问题，其实不然，一些工作经验两三年的同学写的代码依然如此。对于一些个人自学意识不够积极、没有团队规范性指引的同学，很容易习惯成“学习半年、然后重复三年无长进”的情况。

Lint会通过源代码去查找：

• 格式问题
• 不遵守编码标准和惯例
• 精确定位程序中可能存在的逻辑错误

高度耦合

这种问题其实是非常普遍的。一个函数几百行、一个文件数千行、一个类几十个方法、方法参数定义随意、没有任何注释、方法与变量命名无明确的语义、数据修改与变更穿插在各种方法中等等。 这样的编码方式，你要去理解它的逻辑往往真的很难，一般只能一块块一行行的去做阅读理解（可能还会开启边看边骂娘模式）。

这主要原因在于开发者个人的基础知识能力、编码经验和意识等的不足。

其实针对这种情况，常见的开源的编码规范都会有所提及。我的建议是这些同学应该好好温习一下面向对象编程、函数式编程、数据结构、常见设计模式，看一看各种开源的编码规范并尝试去真正的理解它们。当你回顾一个月前的代码时，发现可以改进或重构使得编码逻辑更为简洁清晰，说明你是在成长与进步的。

经常看到有同学问这类问题：新项目正在选型，Vue.js、React、Angular 三大框架哪个合适？其实团队开发成员对这些都比较有经验，哪种都可以；如果团队成员前端开发经验大都不是太丰富或人员不够稳定，选择 Vue.js 最适合，为什么？因为它更简单简洁，容易上手。Vue.js 通过 prop、data、computed、method、watch 等各种钩子，一定程度上限定了编码方式与风格，使得初级开发者写出来的代码也不会太难看，这也是它越来越受社区推崇的原因之一。

代码质量监测（Def: Lint Code）

那么，什么是代码质量监测？

Lint或者Linter是一种分析源代码以标记编程过程中（代码、样式、构建）书写的错误的工具或者过程。

Lint, or a linter, is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs.[1]#citenote-1) The term originates from a Unix utility that examined [C language](https://en.wikipedia.org/wiki/C(programminglanguage)) source code.[[2]](https://en.wikipedia.org/wiki/Lint(software)#cite_note-BellLabs-2)

代码Lint是动态的监测代码编写的错误，以便我们能写出高质量的代码。

与Prettier或者Format要区别开来，Lint只会告诉你代码中的错误或者不符合规范的地方，而Format是用来对格式进行调整的。

如何进行代码质量监测(How to Lint)

为了统一团队的代码规范，除了一纸规范说明之外，还需要引入工具进行限制。虽说工具并不能完全实现规范中的规则，但至少能够在一定程度上缓解代码不统一的局面。

相对于后端，前端代码规范的质量检查涉及到HTML, CSS，Javascript ，如今还涉及到SCSS，ES5，JSX, React，Vue，Angular等。

常见的代码质量Lint工具：

HTML / tpl: HTMLHint官网

CSS / SCSS: StyleLint官网

JS / JSX: ESLint官网

3种常见的Js检验工具比较

常见三个可以使用的js校验器，但是怎么选择使用哪一个呢？接下来让我们看看这四种流行方案的特点、优点和不足：JSLint、JSHint、ESLint。

四种工具用相同的基本方式工作。他们都有一套用户分析、报告js文件错误的规则。他们都可以通过npm安装。他们都可以通过命令行使用、作为IDE插件使用、也可以集成到编辑器中。他们四种均支持使用注释进行配置。

JSLint

JSLint是其中最老的工具。在2002年 Douglas Crockford开发了该工具，根据其经验，强制使用js语言中精粹的部分。如果你同意这些精粹，JSLint能成为一个好的工具。

JSLint的缺点是不能配置和拓展。你根本不能禁掉需要特性，并且很多缺少文档。官方文档非常不友好，例如缺少如何将其集成到编辑的信息。

优点

• 参数配置完成，可以直接使用

缺点

• JSLint不存在配置文件，如果想改变参数设置，那就存在问题
• 有限的配置选项，许多规则不能禁掉
• 不能增加个性化规则
• 没有文档记录规则
• 很难弄清楚哪个规则引起的错误

JSHint

作为一个可配置的JSLint版本，JSHint被开发出来。你可以配置每个规则，将其放到一个配置文件中，这样在大项目中可以容易使用。JSHint对每个规则有好的文档，所以可以准确知道每个规则的作用。将其集成到编辑器也是简单的。

JSHint的一个小缺点是里面的松散默认配置。也即是你在使其可用之前必须将其启动。和ESLint相比，确定哪个规则用户开启或关闭错误信息，JSHint是更加困难。

优点

• 大多是参数可以配置
• 支持配置文件，在大项目中容易使用
• 已经支持需要类库，像jQuery、QUnit、NodeJS、Mocha等
• 支持基本的ES6

缺点

• 难于知道哪个规则产生错误
• 存在两类选项：强制选项和松散选项。使得配置有些混乱
• 不支持自定义规则

ESLint

ESLint是比较新出来的工具。它被设计的容易拓展、拥有大量的自定义规则、容易的通过插件来安装。它给出准确的输出，而且包括规则名，这样可以知道哪个规则造成了错误。

ESLint文档多少有些混乱。规则容易查找，以及被分为逻辑组，但是配置指南在有些地方容易弄混。然而它可以在一个地方提供链接去编辑集成、插件和样例。

优点

• 灵活：任何规则都可以开启闭合，以及有些规则有些额外配置
• 很容易拓展和有需要可用插件
• 容易理解产出
• 包含了在其他检查器中不可用的规则，使得ESLint在错误检查上更有用
• 支持ES6，支持JSX的工具
• 支持自定义报告

缺点

• 需要一些配置
• 速度慢

JSCS已经合并到ESlint

总结一下：