目下のところ JSHint と JSLint 戦争は ESLint という第三勢力の登場によって僕の中でめでたく終結したので最近の JS 開発の際には ESLint を使っている。で、以下の .eslintrc （プロジェクト単位に作れる ESLint の設定ファイル）が僕の場合の基本形。欲しくなったルールをなんか秘伝のタレ的に下に下に継ぎ足してるので、特に定義の順序には拘ってない。

{
    "rules": {
        // 定数式による条件を警告
        "no-constant-condition": 1,
        // 情報が不十分な JSDoc を警告
        "valid-jsdoc": [2, {
            "requireReturn": false
        }],
        // console メソッドを注意
        "no-console": 1,
        // alert メソッドを許可
        "no-alert": 0,
        // debugger メソッドを注意
        "no-debugger": 1,
        // 正規表現におけるスペースの利用を許可
        "no-regex-spaces": 0,
        // シングルクオートを強制
        "quotes": [2, "single"],
        // 厳密等価演算子を強制
        "eqeqeq": 2,
        // 連続スペースの許可
        "no-multi-spaces": 0,
        // ドット記法以外（ブランケット記法）を許可
        "dot-notation": 0,
        // strict 強制を緩和
        "strict": 0,
        // 末尾セミコロンを強制
        "semi": [2, "always"],
        // const or let を強制
        "no-var": 2,
        // 再代入がない限り const を強制
        "prefer-const": 2,
        // カンマ位置は末尾に強制
        "comma-style": [2, "last"],
        // カンマ前後のスペースを許可（垂直方向に統一されたインデントを得るため）
        "comma-spacing": 0,
        // インデントスタイルは4スペースに強制
        "indent": [2, 4, {
            'SwitchCase': 1,
        }],
        // Key:Value におけるコロン前スペースなし、コロン後1スペースを強制
        // ただし垂直方向にコロン記号を揃えるためのコロン前スペースを認める
        "key-spacing": [2, {
            "beforeColon": false,
            "afterColon" : true,
            "align"      : "colon"
        }],
        // 連続した空行を注意
        "no-multiple-empty-lines": [1, { "max": 1 }],
        // 関数呼び出しの際のスペースを禁止
        "no-spaced-func": 2,
        // return, throw,case 句の後のスペースを強制
        "space-return-throw-case": 2,
        // ブロック開始前のスペースを強制
        "space-before-blocks": 2
    },

    "ecmaFeatures": {
        "modules": true
    },

    "env": {
        "es6": true
    }
}

以下適当な注釈。

警告・禁止・強制と注意に分けている基準は？

警告は即座に直して欲しいもの。注意は書いてデバッグしてーって最中ならやってもいいでしょ、というラインで分けている。 console メソッド や debugger だとかはデバッグで結構やる。1行以上の連続空行も編集中にちょっと分かりやすく、大げさに改行を作ったりするので、そういった場面に対応させている。もちろん注意がついたまま git-flow なんかで develp ブランチに上げようものなら殴るとグッド。

ドット記法とブランケット記法許可するの？

ドット記法で文法上無理な書き方を得るため。

特に Backbone.js を利用したアプリケーション開発から得られた知見で、ブランケット記法が欲しいというシーンが発生した。 Backbone.View に渡すテンプレートを外部ファイル化し、JST.元ファイル名 という呼び出しで得られるようにしていた。ただし、元となる外部ファイルのディレクトリでの配置がサブディレクトリまで入ると、JST.サブディレクトリ名/元ファイル名 という呼び出しをしなければならなくなる。ドット記法の場合このようなスラッシュを含む書き方は無理なので、そういった経緯もブランケット記法を許可する要因となっている。