Pocket


著者のダグラス・クロフォードは、 JSONを広めた人であり、JSLintの開発者です。

本当の書き間違いが目立つようにするための、JavaScriptコードの書き方やルールを説明しています。

この本の9章のルールをチェックする文法チェッカーがJSLintで、npm版がjslintです。jslintはかなり厳しいチェッカーです。合格させるためには、多くのコードの修正が必要です。

あまりにもルールが厳しいので、別の開発者がルールをゆるくしたjshintをフォークしたそうです。JSLintからJSHintをフォークした理由

こんなに厳しいルールが本当に必要だろうか、なぜこんなに厳しいルールなのだろうか、と思ったことがきっかけで、この本を読みました。

私はifやwhileなどの構造化された構文では常にブロックを利用する。なぜならその方が間違いを起こしにくいからだ。

9章 スタイル p111

{}をつけたほうがいいと多くの人が言っています。{}があったほうが、ここがブロックだ!と強調されて、より間違いにくいです。

私は、本当の書き間違いが目立つようにしたいと思っているのだ。同様の理由から、代入式をif文の条件部分で利用することを、私は決してしない。

9章 スタイル p112

これは、次のようなことだと思います。

JavaScriptには、自動的にセミコロンを挿入するメカニズムがある。これに依存するプログラムを書いてはいけない。

付録 A.3 セミコロン挿入

セミコロンのメカニズムは知っていましたが、この問題を初めて知りました。

parseIntは、最初の文字が「0」だった場合、文字列を10進数ではなく8進数とみなす。parseInt("08", 10)のように、常に基数をパラメータとして渡すことをおすすめする。

付録 A.7 parseInt

ぼくもこのバグを書いてしまったことがあります。このルールを意識したのは、jslintに注意されてからです。

いまでもparseIntを基数なしで書いてしまい、jslintなどに注意されてから修正することがしばしばあります。

これらの演算子(++と--)を今後使わないというルールを自分に課した。

付録 B.7 ++ --

式の中で使うと、前置の++aと後置のa--は、結果が異なります。aの値を評価してから、aの値をインクリメントする。aの値をインクリメントしてから、aの値を評価する。説明するのも、覚えるのも難しいです。

Switft3で ++と--がなくなりました。そこで、ぼくもJavaScript以外の言語でも、++ と -- を使わないようにして、a += 1 か b -= 1を使うようにしました。