著者のダグラス・クロフォードは、 JSONを広めた人であり、JSLintの開発者です。
本当の書き間違いが目立つようにするための、JavaScriptコードの書き方やルールを説明しています。
この本の９章のルールをチェックする文法チェッカーがJSLintで、npm版がjslintです。jslintはかなり厳しいチェッカーです。合格させるためには、多くのコードの修正が必要です。
あまりにもルールが厳しいので、別の開発者がルールをゆるくしたjshintをフォークしたそうです。JSLintからJSHintをフォークした理由
こんなに厳しいルールが本当に必要だろうか、なぜこんなに厳しいルールなのだろうか、と思ったことがきっかけで、この本を読みました。
私はifやwhileなどの構造化された構文では常にブロックを利用する。なぜならその方が間違いを起こしにくいからだ。
9章 スタイル p111
// 悪い例
if (a)
b();
// 良い例
if (a) {
b();
}Code language: JavaScript (javascript)｛｝をつけたほうがいいと多くの人が言っています。｛｝があったほうが、ここがブロックだ！と強調されて、より間違いにくいです。
私は、本当の書き間違いが目立つようにしたいと思っているのだ。同様の理由から、代入式をif文の条件部分で利用することを、私は決してしない。
9章 スタイル p112
これは、次のようなことだと思います。
// 悪い例
if ((a = b) === c) { ... }
// 良い例
a = b;
if (a === c) { ... }Code language: JavaScript (javascript)JavaScriptには、自動的にセミコロンを挿入するメカニズムがある。これに依存するプログラムを書いてはいけない。
付録 A.3 セミコロン挿入
// undefinedを返す
return
{
status: true
};Code language: JavaScript (javascript)セミコロンのメカニズムは知っていましたが、この問題を初めて知りました。
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を使うようにしました。
