jshint, jslint, eslint では今のところ eslint 一択が良さそう

まだ「完全に確定」してはいないけど。

jshint は思想が NG だが現在のものが「箸にも棒にもかからない」ことはなくて、「たまに使うのにはいいかも」はほぼ自分的には評価確定。

jslint はドキュメントがダメ過ぎるということが一番大問題で、なんというか「言われたからチェックしてみました」というチェックをして「叱られたから直します」というバカ向けにしかなってないような気がしてきた。つまりあまりにもチェック結果の意味が不明過ぎる。なんだろか、英語がおかしくない?

なのでね、jslint のやってくれてることがそんなに悪くないもんで後ろ髪引かれる想いもないでもないんだけれど、なんであれ「チミはいったい何を言いたいんだい?」があまりにも多過ぎて、肝心の本題(コードを良くする)方に神経が全然行かない。こりゃぁワタシにはかえってストレスだ。

というわけで、「TDD サイクルに完全に乗せてまで使う」のはもう ESLint だけでいいかなと。こっちはいちいち全部に「根拠」が説明されてるので、チェック結果の判断をしやすいし、「じゃぁどないせぇちゅうねん」も比較的導出しやすい。つまり「多少ヘンなチェックをしてくれたとしても」、常識的な判断で適用・非適用の決断が出来る。ほかの2つは「たまにほかの観点が欲しくて気紛れに」使えば良かろう。さすがに jshint も jslint も「零点」ではないからね。


追記:
書く前に気付けば良かった。ESLint のドキュメント、滅茶苦茶いい。ちゃんと「When Not To Use It」まで書かれてる:

実際こういったもろもろの整備がなくて非常に困った経験は数知れず。つまり、こういうのって、プロジェクトへの適用は注意深くやらなければいけなくて、そうしないと「叱られたから意味もわからずコードを引っ掻き回す」末端エンジニアが後を絶たないことが頻発し、あるいは「チームメンバー間の不協和音」すらもたらすことがある。

「叱られたから意味もわからずコードを引っ掻き回す」と何が起こるか、なんて常識的に考えれば「当たり前のこと」しか起こらない。つまり「スタイルを良くすることでアプリケーションをぶち壊す」。振る舞いが少し変化する程度で許容出来る場合はまだマシで、「checkstyle の結果を受けて「修正しました」」として製品の仕様を捻じ曲げるバカも大量発生することになる。

「チームメンバー間の不協和音」とはすなわちこれは「一種の技術格差」の問題である。「When Not To Use It」みたいなことが、きちんと理論立てて説明されていないと、「このケースではスタイルチェッカーの不平を聞いてはならない」というまともな判断が出来るエンジニアの方が「非難される側」になりがちである。すなわち、「厳格に従うのがルールだ!」「スタイルチェッカが不平を言うのは万死に値する!」というわけである。これが不和をもたらすことがある。(不和、というほどではなくても、後輩が「いや、だって…」とひたすらに気に病むのをなだめるのに苦労する、というような構図にもなる。)

このことがあまりにも問題だったために、前に何かのチェックツールに対する「傾向と対策」を綺麗にまとめたことがある(checkstyle 以外の java 系の何かだったと記憶している)。実際それは「オリジナルの英語の文書」があったので、ワタシはそれにコメントしていくようなスタイルでまとめてた、かな、確か。全部自分で書いたっけ? いやぁ、違うよな。随分前のことなので詳細は全く憶えてない。ともあれ、こうしたことが問題となりうるようなプロジェクトでは、これは必ずやった方がいいぞ。簡単には「こういうケースで検出された場合は対象外」という特例を明記することが最低限。そして「このケースではこう修正することを推奨する」という、正しい方向に導くような示唆を付けておく。これは簡単なことではないが、一定上の経験数を持ったエンジニアがこれを書くべきだろう。



Related Posts