部落の先端コード規範の実践に興味があります.

チームに入ったばかりの時、チームの中には統一コード規範がありません.大多数の人は良好なコードスタイルを持っていますが、やはり習慣に違いがあります.コードの中に多くのスタイルが一致しない状況があります.だから、チームコードのスタイルを統一する試みを始めました.この過程を整理してまとめます.
ESLINE
業界では主に4種類のJavaScriptコードチェックツールを使っています.JSLint、JSHint、JSCS、ESLintはなぜESLintを選択しますか?文章A Comprison of JavaScript Linting Toolsを参考にしてこれらの四つのツールの長所と短所を比較することができます.総じて言えば、私達は主にESLintの以下の長所を気に入ります.

規則が全面的で、各規則が構成できます.

ES 6とJSXをサポートします.

出力結果は分かりやすい.

新規.eslintrc-alloy.js

module.exports = {
  parser: 'babel-elint', //   ESLint     Babel parser
  parserOptions: { //      
      ecmaVersion: 2017, //    5，     ES5   。2017    ES2017
      sourceType: 'module', //    ‘script’，‘module’       ECMAScript   
      ecmaFeatures: { //            
          experimentalOjbectRestSpread: true, //         object rest/spread properties    
          jsx: true //    JSX
      }
  },
  env: { //        
      browser: true,
      node: true,
      commonjs: true,
      es6: true
  },
  plugins: [
      'react'
  ],
  root: true, //    ESLint           
  rules: {
      ...
  }
};

プロジェクトのルートディレクトリの下に「.eslintrc-alloy.js」ファイルを新たに作成します.これは私達のチームコード規範の核心です.単独で一つのファイルにする目的はチーム全体のコード規範を管理するためです.もう一つは後期のオープンソースのためです.
ESLint Rulesを移転します
公式サイトのすべてのRulesを「.eslintrc-alloy.js」ファイルのrulesに入れます.これは細心と忍耐が必要な時です.各ルールの値は以下の一つです.

offまたは0:ルールを閉じる.なぜ二つの方式で表現しますか?最初は数字を使っていましたが、語義化が非常に悪いことが分かりました.文字列に変えました.前の互換性のために数字を残しました.今は文字列の使用を勧めています.

warnまたは1:規格に合わないコードを確認して警告を提示します.一般的にこれを使わないです.プログラマは常にwarningを無視しています.

errorまたは2:規格に合わないコードプロンプトエラーが検出された.

この3つの値を配置する以外に、ruleにはoptionsがあるので、追加の配置が必要です.例えば、第二条rule getter-returnにはallowImplicitのオプションがあり、undefinedに戻るかどうかを示しています.

'getter-return': [
  'error',
  {
    'allowImplicit': false //       undefined
  }
]

ESLint配置ruleの方式はおかしいです.ruleの値はStringでもいいし、Number(0/1/2)でもいいです.また、Arayでもいいです.0番目はルールのクローズ/警告/オープンです.前と同じように、1位と後面はObjectでもいいです.Objectの例は上記のgetter-returnオプションのようです.Stringの例は第5条rule no-cond-assignのようです.

'no-cond-assign': [
  'error',
  'always'
]

条件語句にはいつでも割り当て語句を使用してはいけないという意味です.具体的にいつObjectを使う時Stringを使って、文書を調べなければならなくて、このruleがどのような書き方を支持することを見ます.
このように文書に照らし合わせて、ルールやルールの配置情報を一つ一つ「.eslintrc-alloy.js」という文書に書きます.ルールのオプション配置はチームの実際状況によって決められます.
コード改造
「.eslintrc-alloy.js」というファイルがあると、チームコードの仕様があります.将来のコードはすべてこの規格に準じるべきです.既存のプロジェクトのコードはどうすればいいですか?直しましょう問題が来ました.プロジェクトはそんなに大きくて、コードが多いです.どこから始まりますか?一日で全部変えますか?直しきれないならどうすればいいですか?いろいろな問題があります.私たちのチームコードの改造の過程を皆さんと共有しましょう.
新規.eslintrc.js

module.exports = {
  extends: [
    './.eslintrc-alloy.js'
  ],
  globals: {
    $: false,
    ...
  },
  rules: {
    ...
  }
};

プロジェクトのルートディレクトリの下で「.eslintrc.js」ファイルを新規作成し、同じディレクトリの「.eslintrc-alloy.js」を継承します.私達の改造の過程は大体「.eslintrc.js」のファイルの中で、すべてのrulesをoffに設定して、それから一つずつ削除して、一つを削除して、この規則に合わないコードを見つけてから修正します.具体的な過程は以下の通りです.
ESLint Rulesを移転します
このステップは、Rulesを「.eslintrc-alloy.js」ファイルに移行するのと似ていますが、今回はrulesをすべて「.eslintrc.js」に移行し、すべてのruleの値を0にし、すべてのルールを閉じるということで、最初からESListがないようになります.
ビルドツール
私達のプロジェクトはgrunt構築プロジェクトを採用していますので、gruntを使って一つのタスクを書きました.grunt eslintを実行すると、プロジェクト全体の中でESLint規格に合わないコードのあるファイルと行数を出力できます.
Ruleをステップごとに削除します
コードの改造はこれから本格的に始まります.毎回一つの「.eslintrc.js」のruleを削除します.「.eslintrc-alloy.js」を継承したから、この規則を開いたのと同じです.grunt eslintを実行して、この規格コードに合わないファイルと行数を見つけて、一つ一つ修正します.修正する時は状況によって違います.ルールを変更したら、すぐに提出してください.後の人はこの規則を使えます.

--fix:公式サイトRulesのリストを見ると、第二列があり、あるruleにスパナのアイコンがあります.その代表ツールは自動的に修復できます.例えば、最初のスパナがあるrule:no-debuggerを実行すると、grunt eslintを実行すると、すべてのdebuggerが削除されます.

コードは簡単です.例えば、no-console規則では、プログラムにconsole.log、console.errorなどの語句を使用することができません.

コードは複雑です.一部の地方コードロジックは複雑です.この時には「脳の変化がない」ということはできません.文脈の意味を知る必要があります.例えば--fixを実行した後、プロジェクト全体の中で5箇所ぐらいがエヴァに使われていることに気づきました.いくつかの低バージョンマシンでno-evalと互換性のある文字列をJSON形式に変換するために使用されるものもあります.文字列を正則に変換するために使用されるものもあります.文脈に詳しいだけが変更できます.そうでないと、ちょっとしたエラーが発生する可能性があるのは数百万人か千万人の利用者です.実際にコードが読めない場合や修正のリスクが大きい場合は、ファイルの先頭にESLintのコメントをつけて、現在のファイルでこのルールを閉じたほうがいいです.

ファイルが多いです.いくつかの規則が開くと、数百件のファイルがあり、千行のコードが間違っていることが分かります.例えば、grunt elsint.このような状況では、修正に最も重要な要素は時間です.ルールを修正するには何日間かかりますか?どうすればいいですか?一つの方法は「.eslintrc.js」の中でこの規則の閉鎖状態を保持しています.JSON.parseを実行する時だけ開きます.規格に合わないコードを見つけたら、すぐにこの規則を閉じます.そして、一つずつゆっくりと変えても大丈夫です.この規則は開かれていないからです.私たちはもう一つの方法を取っています.「.eslintrc.js」でこの規則を削除して、この規則を開いてから、ルールに合わないコードを修正して、修正が間に合わないコードについてスクリプトを書きました.規格に合わないファイルの頭にESLint注釈を付けて、ルールを閉じて、次に頭の注釈を削除して、規範に合わないコードを修正します.このようにするメリットは適時に規則を開けて、他の人が新たな不適合コードを追加しないようにすることです.

他:他のコードの難易度は中ぐらいで、エラー個数も中ぐらいです.よく直してください.

以上の手順を改造作業をほぼ終えました.
コードのメンテナンス
コードの改造を経て、この時遠隔倉庫から引いてきたコードは全部コードの規格に合っています.新規コードも全部合格するように保証するにはどうすればいいですか?私たちは主に二つのことをしました.一つは最新のエディタ、例えばAtomやVSBCodeを使って、両方とも豊富なプラグインがあります.コードを書いているうちに、どのようなところが規格に合わないかが分かります.もう一つの件はシナリオを書きました.コードpushから遠隔倉庫に行く時にこのスクリプトを実行してコードの仕様を確認します.もし規格に合わないところがあったらアップロードを中止します.同時にエラーメッセージがあります.
改造されたコードはより快適でメンテナンス性も高いです.もしあなたのチームにも同じ問題があれば、改造を試みてみてください.