jshint のポリシーには共感出来ない

あんまり人が集まらないでくれることを祈る。

こういう見出しってどうも経験的に危険な気がする。ともあれリラックスして読んでくれ。

ちょっとずつ本格的に使おうと、ドキュメントもちゃんと読み出したんだけれど。というかね、「Functions declared within loops referencing an outer scoped variable may lead to confusing semantics.」の意味がさっぱり取れず、何言ってんだろうか、とドキュメントを読もうとしたんだけれども。

その本題よりも前に、なんだかやたらに「Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness.」が大量に目に飛び込んでくるわけだよ。

あー…、なんか lint の本来の役目を忘れてるな? このチーム。

そもそも lint はその名の示す通り「落ち穂拾い」。元となった C 言語のための lint は、「コンパイラがやってくれない「落とし穴回避のための示唆」」「書き手のみならず読み手にとってもためになるベストプラクティス」をこそ示唆するために生まれたものである。つまり、「正しく動くつもりになったつもりになってればそれでいい」という考え方をプログラマにさせないように、つまり、たとえば Python で言うところの「readability count」も一緒にアドバイスしてくれるもの、だったはずだ。

つまり、「lint 系ツール」というのは、「動けばそれでいっしょ」「オレがわかればいっしょ」という個人主義を排除するために使うもんなんではねーの?

実際 java の checkstyle 経験者も良くわかると思うけれど、とかくこの手のチェックツールは「うるさい」。大きなお世話だ、と思うものが多い。そして結構なものが「動けばいいコードにとっては全く価値のない」ものが多い。

たとえば「一行 80 カラムルール」なんてのがその最たるもんだ。けど、どのルールも「ちゃんと理由があって」それが推奨されている、ということについては、これは「ちょっとだけいつもと違う開発環境で作ってみる」ということをするだけで大抵すぐにわかる。(80文字ルールの件なら、たとえば emacs なら ctrl-x 2 とか ctrl-x 3 でバッファを分割するとか。) すなわち、そういうものというのは、「とても多くの人たちが経験してきた困ったこと」に備えるように考えられてる。(これみたく「なんも考えてへんやろ」てのもたまにはあるが。) そう、得てしてこの手の標準は「不毛な宗教論争から開発者を守る」という思いを持って作られていて、そうした「小さな精神疲労が積み重なることによる品質低下」を防ごうとしてきたわけである。

だから「うるさい」と思っても守る、というのがこの手の lint 系ツールだし、期待するのは「プログラムの正しさとは関係のないところに煩わされたくない」ということでもあるのだ。

しかるに「is limiting its scope to issues of code correctness.」は。わかってねぇなぁ、てことなんじゃねーの? (どうやら元にした jslint から機能を削除していこう、てことらしい。)

まぁ…、好意的に言えばさ、「lint と言う名前を付けていないのだから」というエクスキューズは認めてあげてもいいさ。そうね、lint じゃないんでしょ。ならいいのかもね。


と、ここまで書いてから、「そういうことがしたいなら JSCS を使えや」と誘導されるので行ってみると、「JSCS has merged with ESLint!」。

ほらみろ。そういうことだよ。「スタイルは別問題」という考え方は、本当に品質を考えたい人にとっては、滅茶苦茶迷惑なんだってば。

実際どうなんだろうなぁ、「全てが ESLint でまかなえそう」なら、もうワタシは ESLint 一択にしたいところなんだけれど、まだ個々の個性が見極められてないからなぁ。将来性まで見込めば JSHint がないのは明白でも、「今使えない」てことではないんだもん。うーん、保留。


12:50追記:
「square bracket より dot notation の方がいいんだぜっ」に共感出来ない、の件と、今回の件で、ほぼ「JSHint を日常的に使うのはやめた」とほぼ心に決めたのだが、こんなコード:

1     if (!isNaN(dt.getFullYear())) {
2         return dt.getFullYear()
3             + "-" + _pad(dt.getMonth() + 1)
4             + "-" + _pad(dt.getDate())
5             + "Z" + _pad(-dt.getTimezoneOffset() / 60, true);
6     }

これを JSHint だけが:

1 Misleading line break before '+'; 
2     readers may interpret this as an expression boundary.

という指摘をするのね。こうしろと言ってるてこと:

1     if (!isNaN(dt.getFullYear())) {
2         return dt.getFullYear() +
3             "-" + _pad(dt.getMonth() + 1) +
4             "-" + _pad(dt.getDate()) +
5             "Z" + _pad(-dt.getTimezoneOffset() / 60, true);
6     }

えっと Python の PEP8 も同じトピックで推奨があったはずだがどっちだったっけか? なんか JSHint と同じだったような気がする。だとしたらなんだ、ワタシは無頓着に PEP8 違反コード書いてたか?

と思ったが、いや、Python の場合そもそも性質が違うね。+ が暗黙の継続行をトリガーしない、ので行継続のバックスラッシュ必要、そしてプラスで終わらないつもりなら迷うことなくどっちみちバックスラッシュ不可欠、という、プラスで終わる終わらないでそもそも違う。(ツールの方の pep8 かけてみたらどっちでも警告されなかった。そうでしたっけか?)

まぁ今は Python の話は置いといて、この JSHint の指摘は有用だったりもするかしら、とも思う。ので…、「TDD サイクルに完全に乗っけて使うのは避けたいが、たまに JSHint する」という使い方がいいのかなぁ、と今のところ思っている。