ESLintをコメントなしに無視するのは悪だ
ESLintとは
今更言わずと知れたものですが、プラガブルな静的検証ツールで、コードの問題発見や記法の統一に用います。
なぜ悪か
コメントなしで以下のようにdisableすべきでないか
/* eslint-disable */
// eslint-disable-next-line
それは、会話をしていないからです。
ESLintは本体とプラグインを用いて、一つ一つすべての設定を任意にon, off設定できます。そして、その設定は使用するapplication, project, 組織の原則として自由に定めることができます。
これを無視をしたい時とは、どのような時でしょうか?
- 知識、経験不足により、原則に反した記述をした時
- 極所的な要因により、原則に反した記述をしなければならない時
- 原則が不適切である時
以上のパターンに分類できると思います。
知識、経験不足により、原則に反した記述をした時
この時、コードは原則に即して修正されるべきです。
記述した人はした理由とそれがなぜいけないのかを理解しないといけません。
本人がDocumentなどを読んで理解することも必要でしょうが、レビューなどでdisableしようとしていることを発見した場合などは特に、その人に意識してもらうためにも導入の会話をするべきと思います。
この場合、適切に修正されるためdisableは使用されなくなります。
極所的な要因により、原則に反した記述をしなければならない時
この時、その要因は何なのかを明確にする必要があります。
要因を明確にし、その対処が本当に適切かどうか確かめるために会話をする必要があります。そして、この部分を後からみる人(or 後で見る自分)に向けて会話をこちらから投げかける必要があります。
この場合、要因を明示したコメントともにdisableが使用されます。
原則が不適切である時
この時、原則が適切に修正される必要があります。
本当に原則が不適切であるのか、それは自分たちのユースケースに限って都合が悪いのか、その都合の悪さは一般のユースケースとの差分を確認してなお許容されるべきものなのか
原則の変更を検証するために、組織内はもちろんのこと時には、外のコミュニティの意見を鑑みながら会話し、検証する必要があります。
この場合、原則が変更され、記法が適切になるためにdisableは使用されなくなります。
おわりに
以上のように、disableが使用されるのは何らかの議論、検証を通るべきであり、コメントなしに無視することは悪であると思います。
特に、1番目のケースで繰り返し無視されることによって、ESLint導入の意味が薄れるということがないようにするためにも、会話起点で、適切に修正と改善を回しながら運用すべきだと思います。
Discussion
このルール入れるとdisableに対して理由を書くことを強制できるので、会話のきっかけになるかもしれないですね。
良さそうですね👀
ありがとうございます!