ESLintでプログラミングを快適にしよう

Visual Studio Code(VS Code)でjavascriptのプログラムを書くときにESLintを導入したらプログラミングが快適になった。

# ESLint 導入のきっかけ

## 変形 const 主義

javascriptの変数を最初に `const`で書くのが変形 const 主義。

const変数に再代入されないことが保証されるのでエラー抑止される。再代入が必要になったときlet変数へ書き換える[^let禁止]。プログラムを読んだときにconst変数は再代入されない、let変数は再代入されることがわかり、可読性が上がる。

変形 const 主義でプログラミングが快適になる。

## strict 主義

`use strict`を使うのがstrict主義。

> strictモードでは、より的確なエラーチェックが行われるため、これまでエラーにならなかったような曖昧な実装がエラー扱いになります。このことにより、コード内に存在する潜在的な問題を早期に発見しやすくなります。
>
> 出典 [use strict”（厳格モード）を使うべきか？](http://analogic.jp/use-strict/)

`use strict`を使っていれば的確なエラーチェックをしてくれるはずだったのに :sweat:

## javascript のプログラム検査は不完全

```javascript
'use strict';

class Test {
    t() {
        return 1;
    }
    t() {
        return 2;
    }
}
```

`use strict`を使っているのにメソッド`t()`の重複でエラーが出ない :rage:

```javascript
class Test {
    constructor() {
        this.t = const function () {
            return 1;
        }
        const this.t = function () {
            return 2;
        }
    }
    const t() {
        return 1;
    }
}
```

メソッドを`const`にする方法がない :persevere:

メソッドの重複エラーをどう抑止しようか悩んでいたとき ESLint と出会った。

## ESLint がよさげ

> 2015 年現在は JSHint が一番メジャーですが、これからは ESLint がよさげです。 JSLint は使われなくなりつつあります。
>
> 出典 [JavaScript の静的解析ツールの比較 (JSLint, JSHint, ESLint)](https://maku77.github.io/js/tool/static-analysis-tools.html)

メソッドの重複エラーを抑止できるならどれでもいいが、試してみた。

# ESLint を導入してみた

## ESLint の使い方

`npm init`して package.json を作り `eslint --init` で .eslintrc.js に大量の静的解析ルールを追加してから使う。package.json がないのに`eslint --init`するとpackage.jsonがないので`npm init`するようにエラーが出る。

`eslint --init` の `Inspect your JavaScript file(s)` でファイルを指定すると、すでにあるプログラムに合わせた静的解析ルールを作成できる。他の場所から .eslintrc.js をコピーしてくるとエラーが大量に出るが、こうすればエラー数が減る。


拡張機能の ESLint を導入すれば Visual Studio Code で静的解析ができてプログラミングが快適になる。

## ESLint の静的解析ルール

### no-undef

.eslintrc.js の env に　webextensions　を追加することで、chrome.tabs.query の chrome 変数が no-undef (宣言されていない)をエラー抑止できる。

.eslintrc.js の globals に直接変数名を追加することでも no-undef をエラー抑止できる。

### no-unused-vars の e を消すべきか

![eslint2.png](https://qiita-image-store.s3.amazonaws.com/0/311399/5d32583b-5e7d-74b6-e1e8-282b5243c4b8.png)

`e` は貴重なドキュメントだ。消すなんてとんでもない。イベント関数とわかるし、e.stopPropagation()やe.preventDefault()に発展するときのためにも残したい。[^e]

`// eslint-disable-line no-unused-vars`と書いてこの行だけエラー抑止させる。

### no-console

.eslintrc.js の "extends": "eslint:recommended" で有効が推薦されている。

コンソール出力はデバッグ目的と思われ、出荷するのに適していない。正しい例に `Console.log()` のカスタムコンソールと書いてある。

カスタムコンソールを作ってみたら、どこでエラーが起こったか分からなくなってしまった。コンソール出力をクリックしたらエラー箇所でなく、カスタムコンソールの行を開いたからだ。

しかし、次のように書くことで解決した。実際の行数を出すようにconsole.logを上書ける。[^console]

```javascript
const DEBUG = true;

const Console = {};
Console.log = DEBUG ? console.log : () => { };
Console.error = DEBUG ? console.error : () => { };
```

出荷時に `DEBUG = false` へ変える。

### no-dupe-class-members

この静的解析ルールでクラスメンバーの重複でエラーが出るようになった :heart_eyes:

### capitalized-comments

`eslint --init` の `Inspect your JavaScript file(s)` で指定するファイルによって、コメントの最初が小文字か大文字か、正反対の静的解析ルールになった。

ESLint の静的解析ルールは***柔軟性があり、絶対でない***。ESLint の静的解析ルールを off へ変更することに躊躇がなくなり、ESLint の静的解析ルールを絶対に守ることを 完全 ESLint 主義と呼ぶことをやめた。


## ESLint のここがすごい

導入してすぐわかることは、変数名をミスタイプしたときに静的解析エラーが出ることだ。

![eslint.png](https://qiita-image-store.s3.amazonaws.com/0/311399/f6cf5aa0-0ec5-3edb-bf7e-505ec56651f9.png)

タイプミスで未使用変数があったときに静的解析でエラーが出ると、プログラミングが快適になる。


[^let禁止]: let 禁止の完全 const 主義について書かれている。 [letをconstにできるケース（とlet使用禁止というルールについて）](https://qiita.com/laineus/items/5b8f51e8823c3f510f0e)
[^e]: javascript の`e`を連想した。[とにかく「e」が書かれているだけのリポジトリが面白い](https://qiita.com/wagase/items/867c38f57fe0bce86495)
[^console]: 悩んでいたとき見つけた。[[JavaScript]行数を出せるようにconsole.logを上書く方法](https://qiita.com/omatoro/items/fb48ac33bb485c25a620)