ESLint 自带规则全笔记

[iugo]

在 TypeScript 之前, 学习 JavaScript/ECMAScript(简称 JS) 最好的老师就是 ESLint.

是 ESLint 让我学习 JS, 并使用 JS 到现在的.

大多数情况下我都是不建议自己完善规则的, 因为 Airbnb 的规则已经足够好用了, React 也有自己的规则建议. 并且 TypeScript 能做的更多.

最近在整理微信小程序的项目, 在为这个项目完善 ESLint 规则的时候, 顺便也整理一份文字出来, 讲讲我这样设置的原因.

我的简短文字更像是笔记, 希望大家对照着 ESLint 自带的规则 来看.

被推荐的规则, 建议大家遵循, 同时建议没看过的同学在有空时翻看一下.

针对没有添加到 eslint:recommended 的, 下面逐一说:

避免错误

no-await-in-loop 不允许在循环中嵌套 await.

🟡 没有使用该规则.

我的原因很简单, 就是当想避免同时并发时, 在循环里 await wait('100ms');fetch('something'); 还是有意义的.

no-console 不允许控制台输出

🟢使用该规则: error.

如果真是希望长期留存输出, 建议大家通过一个函数进行包裹, 然后仅在该函数中使用, 然后通过注释 disable-eslint 来避免报错.

no-extra-parens 不使用没必要的括号.

🟢使用该规则: error.

这里有一些小知识点, 比如算术运算符是遵循数学的, 乘除号优先级一样, 但逻辑运算符可不是. 推荐大家看看MDN 关于运算符优先级的相关文档, 比如 && 是优先于 || 的.

no-template-curly-in-string 普通字符串中不使用参数占位符

🟢 使用该规则: error.

为了避免本来使用重音符但使用了引号的情况, 要求普通字符串中不能出现参数占位符. 是一点限制, 但基本不会有人故意在普通字符串中非要使用参数占位符, 如果非要, 那就用编码吧, 比如 '\u0024{}'.

[7.0] no-useless-backreference

🟡 没有使用该规则.

这是最近才添加的新规则, 关于字符串正则的, 我们很少写正则.

因为 7.0 版本还在测试, 直接进入 404, 可以通过这里看文档.

require-atomic-updates 涉及异步时, 优先执行异步

🟢 使用该规则: error.

虽然我们尽量写纯函数, 避免这种用法是可能的. 之所以会出现这样的问题, 也算是因为 JavaScript 的糟粕吧, 没有指针.

最佳实践

accessor-pairs 要求 Get 和 Set 同时出现

🟢 使用该规则: error.

如果只 Set, 没有 Get, 那么使用 Set 就是毫无意义的. 不过反之则可能是真实需求, 所以使用默认规则只限制前者即可.

array-callback-return 数组某些方法的回调函数要求一定有返回值

🟢 使用该规则: error.

我们遇到过本该使用 for 却使用 map 的代码. 该规则能一定程度上避免问题, 但无法检测出有人随便返回了一个值的情况. 所以还是要大家统一思想啊, 尽量写明确, 简洁, 清晰的代码.

block-scoped-var 无视 var 的作用域 hoisting

🟡 没有使用该规则.

在没有 let/const 时, 这个功能有用. 在 ES6 之后, 使用 no-var 就可避免这种语言问题.

class-methods-use-this 类的方法必须使用 this

🟢 使用该规则: error.

如果一个类的方法没有使用到 this, 那么写成静态方法或者纯函数更好.

complexity 嵌套复杂度

🟢 使用该规则: ["error", 10]

尽量将每个函数写小一点, 增加代码可读性. 但考虑到整体团队和项目具体的情况, 需要选择一个合适的值.

consistent-return 一致性的返回

🟢 使用该规则: error.

帮助我们思考, 这个函数为什么要这样用, 该不该这样用, 同时避免一些低级错误如 map 的特殊情况忘了返回默认值.

curly 要求写大括号

🟢 使用该规则: error.

主要算是代码风格上的要求. 但也是因为 JS 的大括号省略规则可读性差, 还是写个大括号吧.

default-case 要求 switch 必须有 default

🟢 使用该规则: error.

主要是为了避免手误.

[7.0] default-case-last 要求 switch 的 default 必须在末尾

🟢 使用该规则: error.

从语义上理解, 将兜底方案放在末尾是可读性最佳的. 可以通过这里看文档.

default-param-last 函数有默认值的参数必须在最后

🟢 使用该规则: error.

在 JS 中函数可以有多个参数, 一般前面的必填, 后面的选填. 否则就会造成使用不便, 每次请求的时候都要传个无效值, 如 foo(undefined, 1). 有默认值的参数都是可选, 所以放在最好方面函数的使用.

另外, 如果有多个可选参数, 建议使用 foo(need, options = {}) 的方式定义函数, 将可选参数都放入 options 内.

dot-location 属性点号的位置

🟢 使用该规则: ["error", "property"].

这是关于风格一致性的约束. 不过实际中我们很少针对对象属性换行, 因为需要换行的时候, 一定是比较长了, 但我们需要避免这么长的命名出现. 如果真的需要, 我们希望在行首能知道, 同时要有缩进.

dot-notation 必须使用点号来访问属性

🟢 使用该规则: error.

如果我们使用驼峰式命名, 那么这个一般是必要的. 但特殊情况下我们要处理后端直接返回的下划线风格命名时, 比如 SQL 列名, 就会出现问题, 建议遇到实际情况并且需要, 再使用 allowPattern 选项来允许特殊情况.

eqeqeq 必须使用全等

🟢 使用该规则: error.

首先, 非全等并不会更快, 因为非全等是做了隐性的类型转换. 其次, 所有隐性的类型转换都是不建议的, 只会让错误更容易发生(哪怕只提升了 0.00001% 的错误概率), 并不能提高开发效率.

在一些情况下, 有人希望使用 == null 来同时判断 null 与 undefined. 但我不建议这样做, 如果需要这样的判断, 单独做一个函数, 在函数内进行 disable rule 就行了.

grouped-accessor-pairs 要求 Get/Set 相邻

🟢 使用该规则: error.

这是一个代码可读性的问题, 一个属性的 Get/Set 要相邻. 这个大家应该都同意吧.

guard-for-in 谨慎使用 for in

🟢 使用该规则: error.

在大多数业务代码中, 都不需要使用 for in, 建议大家使用 for of 替代. for in 会遍历原型链, 一是没必要的慢, 二是很多时候我们不知道原型链中有什么.

现实情况可能是大家不知道这些个 for 循环都有什么区别, 尤其是被网上的一些代码带偏了. ☹️

max-classes-per-file 强制规定一个文件里面类的数量

🟢 使用该规则: error.

以前 React 没有 Hooks 时经常写类, 现在前端很少写类了. 后端 Node.js 在数据操作上, 还是有类的. 每种数据一个类, 一个文件, 管理起来很方便.

no-alert 禁止使用 alert 等直接涉及 UI 的函数

🟡 没有使用该规则.

虽然历史原因是全局的, 但实际这些应该是 Window 的方法. 平时基本不会这些函数. 微信小程序等也是没有这些 Web API 的. 虽然会与 UI 界面不符, 但我真的希望浏览器能把这个功能做好, 我想用. 🌞

no-caller 禁止匿名函数内部自调用

🟢 使用该规则: error.

出于性能考虑, 在 ES6 之后, arguments 就是不被推荐的了. 解决方法就是给函数命名.

no-constructor-return 禁止构造函数的返回

🟢 使用该规则: error.

在构造函数中设置 return 是没有意义的. 如果出现, 一般都是写错了.

no-div-regex 避免可能与除法混淆的正则写法

🟢 使用该规则: error.

使用引号来表示字符串, 使用 / 来表示正则. / 同时也可以表示除号, 这种一个符号两种用法在特定情况下会让人不容易理解.

no-else-return 不使用没必要的 else

🟢 使用该规则: error.

梳理一下逻辑, 使用最简单有效并且可读的做法. 这个例子在我初学时对我影响很大. 初学时, 最大的疑问就是, 什么才算好代码?

no-empty-function 避免空函数

🟢 使用该规则: error.

一般只有在未完成的时候才会保留空函数, 这个规则考虑到了该情况, 如果函数内有一些注释, 则不会报错.

no-eq-null 禁止与 null 进行非全等比较

🟡 没有使用该规则.

不是说这个规则没用, 是因为 eqeqeq 规则已经做了限定.

no-eval 禁止将字符串当作代码执行

🟢 使用该规则: error.

函数如其名. 这样做是非常不安全的.

no-extend-native 禁止扩展原生对象

🟢 使用该规则: error.

对于大多数业务代码来说, 不要修改标准库, 任何情况下都可以找到替代方案.

no-extra-bind 禁止不必要的绑定

🟢 使用该规则: error.

fn.bind() 的目的是用来在函数运行时指定 this 而不是使用当前 this, 如果函数内没有用到 this, 就没有任何意义.

no-extra-label 禁止使用不必要的标签

🟡 没有使用该规则.

我们会通过 no-labels 来禁用标签, 所以这条规则没有使用.

no-floating-decimal 禁止浮点数省略 0

🟢 使用该规则: error.

怎么说呢, 我认为这也是 JS 的语法糟粕. 不过还好, 在项目中我暂时没有遇到有人这么写代码.

no-implicit-coercion 禁止隐晦的类型转换

🟢 使用该规则: error.

依然是 JS 的语法糟粕. 但类似 '' + something 的写法我还是见过的.

no-implicit-globals 禁止隐晦的全局声明

🟡 没有使用该规则.

在 no-var 规则开启的时候, 这条规则失去了原有的意义. 而且现在项目都是模块化的代码, 所以没必要使用这条规则.

no-implied-eval 禁止使用隐性 eval

🟢 使用该规则: error.

类似 no-eval 规则.

no-invalid-this 禁止无效的 this 引用

🟢 使用该规则: error.

很多时候, 无效的 this 引用并不是说 this 是 undefined, 而是没必要这样去引用 this. 比如浏览器中, 全局使用 this 等同于 window, 使用 window 就好, 没必要使用 this. 还是让 this 只出现的类中吧.

no-iterator 禁止使用 __iterator__ 属性

🔵 可选使用该规则.

在 ES6 以后, 使用迭代器来替代 __iterator__ 的功能. 禁用主要因为 __iterator__ 并不是一个标准.

no-labels 禁用标签

🟢 使用该规则: error.

我从来没有见过有人使用 label 语法, 这语法本身的含义也让我困惑. 不过还好, 我知道, 它没用, 完全可以被更简单清晰的语法替代.

no-lone-blocks 禁用不必要的大括号

🟢 使用该规则: error.

大多数情况下, 应该是手误提醒. 但在我开发的经验中, 没有遇到这种情况. 不过需要注意的是, 任何大括号都会创建一个作用域, 虽然这点在特殊情况下可能会有用, 但一般都可以使用另一种写法而没必要特意创建一个作用域.

no-loop-func 禁止在循环中声明函数

🟢 使用该规则: error.

在循环中声明函数一般是为了将循环中的变量传入到函数中执行. 但我们不应该滥用闭包, 纯函数就能避免潜在的问题. 比如除了避免使用 var 的方法外, 我们还可以在使用 var 时这样做:

let funcs = [];
let t = v => (() => v);
for (var i = 0; i < 10; i++) {
    funcs[i] = t(i);
}

我不是在鼓励大家使用 var, 而是在鼓励大家写纯函数并且善用闭包而不是滥用闭包.

no-magic-numbers 禁止使用魔术标识符

🟢 使用该规则: error.

在这里, "魔术" 的意思是不知道是怎么回事儿, 但就是起作用了. 该规则主要是希望使用更良好命名的常量来规范代码. 触发该规则的大多数情况是在开发初期, 为了方便快捷而为之, 但无论如何, 良好的命名对整体工作都是有利而无害的.

no-multi-spaces 禁止多个空格

🟢 使用该规则: error.

主要是代码风格上的规范. 让代码整体上可读性更好. 如果经常触发该规则, 可能是键盘的空格键坏了. 😛

no-multi-str 禁止多行字符串

🟢使用该规则: error.

普通字符串的多行一般都是出错了. 如果在字符串中手动添加了换行符, 现在一般使用模板字符串来做字符串的多行, 这是一个比换行符更简单直观的办法.

no-new 禁止单独使用 new

🟢 使用该规则: error.

如果不为赋值, 没必要使用 new. 如果构造函数中有什么想要做的, 写成纯函数更好.

no-new-func 禁止使用 Function

🔵 可选使用该规则.

没必要把一个简单的事情做复杂, 尤其是 Function 的参数还有 eval 的味道.

no-new-wrappers 禁止在原生类型上使用 new

🟢 使用该规则: error.

在做类型转换的时候 Number 等还是比较常用的, 但需要注意的时候, 这些时候都不能在前面加 new. 为了防止意外, 这条规则还是有意义的.

no-octal-escape 禁止出现八进制字符转义

🟢 使用该规则: error.

在一些特殊情况下, 我们会使用字符转义. 现在基本所有编程语言都不支持八进制字符了, 均为 Unicode 或十六进制. 虽然 Unicode 会使用十六进制来表示, 但建议统一使用 Unicode, 即 /u 开头.

no-param-reassign 禁止修改函数的参数

🟢 使用该规则: error.

在我看到的代码中, 这条规则非常不容易被遵守. 有些时候从性能考虑, 我们想直接修改函数外的变量. 但其中很多时候, 我们都在冒潜在的风险, 因为我们不知道将来谁还会使用这个函数.

我建议还是将此规则打开, 如果需要, 在函数处写好注释然后临时关闭该规则.

no-proto 禁止使用 __proto__

🟢 使用该规则: error.

这是已被标准丢弃的用法, 但我曾多次看到互联网上有古老的代码使用了这一特性. 目前这一功能仅应该在兼容库中看到, 而我们使用的东西早已不支持 IE6, IE8 了.

no-restricted-properties 禁用对象某属性

🔵 可选使用该规则.

根据需求自定义禁用任意对象的任意属性. 在庞大并且有历史的项目中, 这个功能有利于规范代码. 但新项目一般是不需要这样做.

no-return-assign 禁止在返回时赋值

🟢 使用该规则: ["error", "always"].

不仅是为了避免手误. 出于 return 语义本身的尊重, 任何赋值, 哪怕使用小括号, 都不该在 return 时出现. 多数情况下一旦返回了, 就不需要赋值. 如果真的需要, 建议写为两行, 一行赋值, 一行 return. 多占用一点空间, 更简单可读的代码.

no-return-await 禁止在返回时 await

🟢 使用该规则: error.

这样做是毫无意义的. 如果一个函数是异步的, 那么函数内 await 是意义是防止后面的代码先执行, 如果没有后面的代码, 就没必要 await.

如果出现仅仅为了在函数末尾 catch error 的情况, 更简单的办法是:

// 不要
async function foo() {
    try {
        return await bar();
    } catch (error) {}
}

// 应该
async function foo() {
    return await bar().catch(errorHandler);
}

no-script-url 禁用 Script URL

🔵 可选使用该规则.

如果是前端工作, 并且是非单页应用, 才可能出现该问题.

no-self-compare 禁止对自身进行比较

🟢 使用该规则: error.

比较自身, 永远是全等的. 这样的比较是没有意义的. 一般出现这样的代码是在测试或者笔误.

no-sequences 禁止在不必要的时候使用逗号

🟢 使用该规则: error.

不建议在除了 for 和 while 之外的任何表达式中使用逗号, 建议仅把逗号作为分隔符使用.

no-throw-literal 只能抛出错误

🟢 使用该规则: error.

首先, 直接抛出任何非 Error 都会让错误处理更复杂. 其次, 有时写抛错会手误, 比如会出现忘记写 new 的情况, 该规则能避免手误发生.

no-unmodified-loop-condition 避免不可预见条件变动的循环

🟢 使用该规则: error.

如果循环条件不发生变化, 那么循环则不会停止, 绝大多数情况这不是我们想看到的. 我们还要避免副作用变化, 即将条件依赖放到函数副作用中, 虽然执行正常, 但会导致代码可读性差.

no-unused-expressions 禁止无意义的表达式

🟢 使用该规则: ["error", { "allowShortCircuit": true }].

为了防止笔误或者忘了将测试代码误带到产品中, 该规则有用. 但逻辑短路的用法还是比较常见, 我们不能说没有意义. 利用三元运算符做逻辑短路则不建议, 会比较难读, 可以写成函数.

no-useless-call 禁用不必要的 .call .apply

🟢 使用该规则: error.

在经常涉及 this 或原型链的上下文中, 可能常用. 该规则禁止的仅是和直接使用函数没有差别的调用, 直接使用函数是效率更高也更简单的做法.

同时, 尽量使用箭头函数来替代固定 this 的用法.

no-useless-concat 禁止不必要的字符串拼接

🟢 使用该规则: error.

如果两个普通的字符串需要用加号连接, 那么它们肯定可以写成一个字符串. 如果上述情况不涉及换行, 那么我们就应该写成一个字符串.

no-useless-return 禁止没有必要的返回

🟢 使用该规则: error.

一般不携带值的提前 return 都是为了阻断后续代码执行, 如果后续代码本来就是不执行的, 那么就没必要写 return. 使用该规则会让代码更简洁, 同时也让我们更清晰梳理逻辑. 触发该规则一般都是测试或者逻辑没彻底弄懂.

no-void 禁用 void 语法

🟢 使用该规则: error.

void 会返回 undefined, 但是 void 后面需要跟随一个任意值. undefined 就是 undefined, void any 也是 undefined. 那么更加语义化的做法就是直接使用 undefined, 避免使用 void.

在 ES5 之前, void 有其历史意义. 但现在 void 已经没有必要了.

no-warning-comments 不使用警告注释

🟢 使用该规则: ["warn", {"location": "anywhere"}].

代码中会留存许多待办注释, 但这可能不是会需要立刻解决的, 所以我们使用了警告而非错误等级来标注出这些地方.

虽然没有不是错误等级, 但该规则是非常重要的, 有利于评估项目整体情况.

prefer-named-capture-group 正则捕获中使用命名代替数组

🔵 可选使用该规则.

只有 ECMAScript 2018 支持该特性. 我们也很少写正则, 所以这个因人而异吧. 但无论怎样, 有命名的可读性都是高于匿名的, 尤其是数组还有多项.

prefer-promise-reject-errors 限制 reject 参数只能为错误

🟢 使用该规则: error.

和 no-throw-literal 规则类似, 配合使用达到最好效果.

prefer-regex-literals 仅在必要时使用 RegExp 构造函数

🔵 可选使用该规则.

该规则认为 RegExp 最大的价值在于创建带参数的正则, 如果正则包含特殊字符串, 使用 RegExp 会有些啰嗦, 比如 new RegExp("^\\d\\.$").

radix 数型转换要求进制

🟢 使用该规则: error.

将字符串转为数字类型时, 必须选择进制, 多写一个参数, 让代码更清晰.

require-await 禁止没有 await 的 async

🟢 使用该规则: error.

如果没有使用 await, 则没有必要将函数改为 async. 如果需要将一个函数转为异步函数, 可以返回 Promise.resolve(). 如果函数没有返回, 那这个函数就不需要是一个异步函数.

require-unicode-regexp 强制正则使用 unicode

🟢 使用该规则: error.

与 no-octal-escape 类似, 编码上统一使用 unicode 能避免意外的编码错误.

vars-on-top

🟡 没有使用该规则.

为了提醒大家 var 有变量提升, 将其置于顶部是有意义的. 但如果使用了 no-var, 则没有必要再用该规则了.

wrap-iife

🟢 使用该规则: ["error", "inside"].

IIFE, Immediately invoked function expression, 立即执行函数表达式. 历史上之所以出现这种东西是为了避免变量作用域污染, 尤其是以前只有 var 的情况下. var 基本上只被函数限制作用域.

但现在基本不会出现该情况了. 但如有历史代码, 还是建议启用该规则.

yoda 禁止 Yoda 语法

🟢 使用该规则: error.

不是说这种用法出错, 是因为我们都无法跟上 Yoda 大师的思维. 我们都是普通人, 用普通的语法就好.

strict 严格模式

🟢 使用该规则: 在 config 文件中进行配置.

parserOptions: {
  sourceType:  'module',
  impliedStrict:  true,
}

变量

init-declarations 强制变量声明规则

🟢 使用该规则: error.

如果函数巨大, 那么在函数顶部提前声明是一种更好的做法. 但我们应该避免这种巨大的函数. 同时, 由于 ES6 作用域的增强, 我们没有必要提前声明可能用到了变量. 所以使用 always, 在声明的时候必须初始化是我们的首选.

no-label-var

🟡 没有使用该规则.

因为使用了 no-labels 规则, 所以该规则没有必要了.

no-restricted-globals 禁用

🔵 可选使用该规则.

根据需求自定义禁用全局变量. 避免使用某些全局变量, 与 `` 类似, 目的是处理在有历史的代码中进行结构优化.

no-shadow 禁止作用域变量重新声明

🟢 使用该规则: error.

最初, 对于此规则我是有犹豫的. 在 ES6 之后, 子作用域内重新使用和外部变量一样的名称并不会导致错误, 并且可以避免一些常用的命名冲突, 比如 v, item, product. 但从可读性来说, 简单的命名并不是良好的做法, 只是在特定区域内简单的做法.

no-undef-init 禁止以 undefined 初始化变量

🟢 使用该规则: error.

可能是写 TypeScript 的原因, 就算 JS 也不愿意进行重新赋值. 现在我们用 undefined 的意义主要在于判断, 我们是不会将其赋值给变量的, 更别说初始化赋值了.

no-undefined 禁用 undefined

🟡 没有使用该规则.

还是基于历史原因, 以前 undefined 会被重新赋值. 现在则不会有类似问题了. 因为使用了被推荐的 no-global-assign 和 no-shadow-restricted-names 规则, 则这个规则的防错意义不大了. 但逻辑梳理上, 还是有意义的. 但鉴于历史代码的原因, 我们没有使用该规则.

no-use-before-define 禁止在定义前使用

🟢 使用该规则: ["error", "nofunc"].

在不使用 var 之后, 如果在声明之前使用变量, 会直接报错, 所以该规则可以避免我们出现一些低级错误.

ES6

arrow-body-style 箭头函数的大括号风格

🟢 使用该规则: error.

这是一个风格约束. 箭头函数的主体有两种格式, 除了普通的大括号用法, 还有一种是省略 return 并直接返回值, 虽然这会带来额外的语法, 但鉴于这种用法的常用性, 使用该规则的默认设置.

arrow-parens 箭头函数的参数小括号风格

🟢 使用该规则: ["error", "as-needed"].

这是一个风格约束. 因为箭头函数经常会在回调中用, 尤其是作为 .then() 的参数. 这时额外加括号看起来啰嗦, 所以仅在必要时添加 .

arrow-spacing 箭头函数的空格风格

🟢 使用该规则: error.

这是一个风格约束. 建议合理添加空格.

generator-star-spacing

🟢 使用该规则: error.

这是一个风格约束.

no-confusing-arrow 禁用模糊的箭头函数返回

🟢 使用该规则: error.

如果允许使用箭头函数直接返回值的特性, 那么在一些情况下可能造成可读性差, 一般我们选择通过小括号的方式增强可读性.

no-duplicate-imports 禁止重复引用

🟢 使用该规则: error.

该规则和用函数增强复用是一种想法. 有利于更简洁的代码, 并且在代码变更时更容易维护.

[7.0] no-restricted-exports 限制可以被导出的变量名

🔵 可选使用该规则.

自定义.

no-restricted-imports 限制可以被 import 导入的

🔵 可选使用该规则.

自定义.

no-useless-computed-key 禁止没有必要的对象 key 计算

🟢 使用该规则: error.

如果不是变量, 没有必要使用中括号. 如 { [key]: 'keyName' } 则是必要的.

no-useless-constructor 避免无效的 constructor

🟢 使用该规则: error.

触发该规则一般是测试或手误. 如果真的在 constructor 中没有代码, 则这个类的意义就不大, 完全可以用普通函数替代.

no-useless-rename 禁用没有意义的重命名

🟢 使用该规则: error.

ES6 之后导出导入及解构时可以直接为变量重命名, 将 a 重命名为 a 是没有任何意义的. 为了避免没有意义的命名, 使用该规则.

no-var 禁用 var

🟢 使用该规则: error.

该规则的好处之前已经说过了, 使用 const, let 替换 var 来避免变量提升, 限制在作用域中.

object-shorthand doc 简写 object 的属性

🟢 使用该规则: error.

这是一个风格约束. 跟随团队习惯选择.

prefer-arrow-callback doc 回调要求使用箭头函数

🟢 使用该规则: error.

箭头函数除了设置 this 之外, 最大的作用就是简化回调的匿名函数. 使用该规则能让统一风格.

prefer-const 尽量使用 const 文档

🟢 使用该规则: error.

ES6 之后区分了 let, const, 但 const 并不是只用于常量, 而是只限制不能直接重新赋值. 完全使用 let 并不会出错, 但在声明的时候严格区分使用可以让代码可读性更强.

prefer-destructuring 尽量使用解构 文档

🟢 使用该规则: error.

为了一致化代码风格, 使用该规则. 有些人喜欢用, 另一些人可能还是喜欢经典的方法, 导致代码内风格比较混乱. 解构是更简单的, 并且在一些情况下表达能力更强.

prefer-numeric-literals 尽量使用字面量进行数型转换 文档

🟡 没有使用该规则.

在 ES6 中, 允许直接做常用的二进制, 八进制, 十六进制的转换. 但我认为使用 radix 规则更好. 所以没有使用该规则.

prefer-rest-params 尽量使用解构代替 arguments 文档

🟢 使用该规则: error.

建议尽量不要使用 arguments. 以前是不得已, 没有很少的替代方案. 可读性上来说, 尽量避免函数使用外部变量, 也不要使用 arguments 这种特殊变量.

prefer-spread 尽量使用解构代替 .apply() doc

🟢 使用该规则: error.

与 no-useless-call 的原因类似, 尽量避免这种用法. 性能, 可读性都不占优.

prefer-template 尽量使用字符串模板字面量 doc

🟢 使用该规则: error.

以前, 字符串拼接的时候引号和加号的使用看上去比较乱, 遇到复杂的情况, 如果没有语法着色, 很难看懂. 模板字符串很好解决了以前的语法不足.

rest-spread-spacing 强制 rest, spread 语法的空格 doc

🟢 使用该规则: error.

这是一个风格约束.

sort-imports 引用排序 doc

🔵 可选使用该规则.

排序是一个良好的做法, 但有些时候需要按照特定需求排序. 比如在 JSX 文件中, 一般都最上面引用 React. 可以根据需求使用该规则.

symbol-description 要求 symbol 描述 doc

🟢 使用该规则: error.

与函数尽量命名类似. 尽量增加描述让代码容易被理解.

template-curly-spacing doc

🟢 使用该规则: error.

这是一个风格约束.

yield-star-spacing doc

这是一个风格约束.

附录

关于如何添加空格:

• 句号, 逗号之后添加空格.
• 大括号两侧添加空格.
• 中括号, 小括号, 引号, 重音符号外留空格, 内无空格.

图例:

🟢 使用该规则.
🟡 没有使用该规则.
🔵 业务代码基本不会触发该规则, 选择性使用.

[iugo]

将来会整理一下 TypeScript 的规则: https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin#supported-rules