これは、有能なJavaScriptプログラミングの厳密なルールセットではなく、すべてのソースファイルの単一の魅力的なスタイルに耐えるための一連の制限です。 JavaScriptにとって、このようなガイドは特に興味深いものです。非常に柔軟で要求の厳しい言語であり、選択の幅がかなり広がります。
最も人気のあるスタイルガイドは、GoogleとAirbnbによって提案されたものです。 JSでの作業に多くの時間を費やす場合は、両方に精通することをお勧めします。 以下に、特に興味深いと思うGoogleマニュアルの13のルールをリストします。 それはすべてに影響します：最も論争を引き起こすつまずきのブロック（タブに対するスペース、セミコロンの使い方に関する議論の余地のある質問）、および私を驚かせたあまり議論されていないポイント。 これらはすべて、間違いなく私の将来のコーディング慣行に影響を与えます。
各ルールについて、要件の概要、マニュアルからの引用、より詳細に定式化された箇所、および可能であれば、違反のあるフラグメントとともに適用例が提供され、比較できるようになります。
タブではなくスペースを使用する
改行文字を除いて、ASCIIのスペース（0x20）は、インデントを示すためにソースファイルに表示される唯一の文字です。 これは、...タブがフォーマットに使用されないことを意味します。
後で、マニュアルでは、インデントを4つではなく2つのスペースに設定する必要があることも明確にしています。
// bad function foo() { ∙∙∙∙let name; } // bad function bar() { ∙let name; } // good function baz() { ∙∙let name; }
必要なセミコロン
各ステートメントはセミコロンで終了する必要があります。 自動貼り付けに依存することは禁止されています。
この抵抗がこのアイデアによって説明される理由はわかりませんが、JSコードにセミコロンを絶えず挿入するかどうかについての議論は最近、スペースとタブの支持者の間の戦争のレベルに達しました。 Googleはセミコロンを支持して決定的な位置を占めています。
// bad let luke = {} let leia = {} [luke, leia].forEach(jedi => jedi.father = 'vader') // good let luke = {}; let leia = {}; [luke, leia].forEach((jedi) => { jedi.father = 'vader'; });
ES6モジュールを使用しないでください（今のところ）
現時点では、ES6モジュールを使用しないでください（たとえば、キーワードをエクスポートおよびインポートするため）。そのセマンティクスはまだ最終的な形式を取得していないためです。 この規則は、セマンティクスが最終的に標準になったときに改訂されることに注意してください。
// Don't do this kind of thing yet: //------ lib.js ------ export function square(x) { return x * x; } export function diag(x, y) { return sqrt(square(x) + square(y)); } //------ main.js ------ import { square, diag } from 'lib';
水平方向の配置は推奨されません（ただし禁止されていません）
この慣行は許可されていますが、Googleのスタイルガイドによって承認されていません。 すでに適用されている場合、水平方向の配置を維持する必要さえありません。
水平方向の配置は、特定の値が最上行の対応する値のすぐ下に配置されるように、任意の数の追加スペースをコードに追加する方法です。
// bad { tiny: 42, longer: 435, }; // good { tiny: 42, longer: 435, };
varはもう使用しないでください
constまたはletを使用してすべてのローカル変数を宣言します。 変数に新しい値を割り当てる必要がない限り、constをデフォルトのオプションにします。 varキーワードは使用できません。
StackOverflowや他のサイトのコード例では、まだvarに出会います。 これらの人々がそのような選択を支持する議論を持っているのか、それとも彼らが古い習慣を手放すことができないのかはわかりません。
// bad var example = 42; // good let example = 42;
矢印関数が優先されます。
矢印関数は簡潔な構文を提供し、それにより多くの複雑さを解決します。 特にネストされた関数に関しては、機能キーワードよりもそれらを優先してください。
率直に言って、矢印関数が好きなのは、見た目が良く、より正確だからです。 しかし、結局のところ、それらはかなり重要な目的にも役立ちます。
// bad [1, 2, 3].map(function (x) { const y = x + 1; return x * y; }); // good [1, 2, 3].map((x) => { const y = x + 1; return x * y; });
連結の代わりにパターン文字列を使用する
文字列が「文字」で区切られているパターンの使用は、特に複数の文字列リテラルが含まれる場合、複雑な文字列の連結よりも望ましいです。 パターンには複数の行を含めることができます。
// bad function sayHi(name) { return 'How are you, ' + name + '?'; } // bad function sayHi(name) { return ['How are you, ', name, '?'].join(); } // bad function sayHi(name) { return `How are you, ${ name }?`; } // good function sayHi(name) { return `How are you, ${name}?`; }
長い行には行の継続を使用しないでください
通常の文字列リテラルまたはテンプレートリテラルのいずれでも、行の継続を使用しないでください（つまり、文字列リテラルの行をバックスラッシュで終了しないでください）。
興味深いことに、ここでGoogleはAirbnbに同意しません（その仕様はここにあります）。 Googleが長い文字列に連結を使用することを推奨している場合（以下を参照）、Airbnbのスタイルガイドでは、何もせず、必要なだけ行を続けるように指示されています。
// bad (sorry, this doesn't show up well on mobile) const longString = 'This is a very long string that \ far exceeds the 80 column limit. It unfortunately \ contains long stretches of spaces due to how the \ continued lines are indented.'; // good const longString = 'This is a very long string that ' + 'far exceeds the 80 column limit. It does not contain ' + 'long stretches of spaces since the concatenated ' + 'strings are cleaner.';
for ... of-最適なforループ
ES6のリリースにより、言語には3種類のforループが存在するようになりました。 これらはすべて適用できますが、可能であれば、for-ofループを優先する必要があります。
私の意見では、これは非常に奇妙なアドバイスですが、私はそれを同じようにオンにすることにしました-Googleがその好きなタイプのサイクルを脇に置いているのは不思議です。 一般的に、for ... inループはオブジェクトにより適し、for ... ofループは配列の処理に適しているという印象を受けました。 つまり、タスクのツールを選択する状況があります。
Googleの仕様がこの考えに反するということではありませんが、彼らが特定のお気に入り、特にこのお気に入りを持っていることを知るのはまだ楽しいです。
eval（）を使用しないでください
eval（）またはFunction（... string）コンストラクターを使用しないでください（例外はプログラムローダーです）。 これらの機能は潜在的な脅威をもたらし、CSP環境では機能しません。
eval（）ページのMDNには、「Never use eval（）！」という特別なセクションもあります。
// bad let obj = { a: 20, b: 30 }; let propName = getPropName(); // returns "a" or "b" eval( 'var result = obj.' + propName ); // good let obj = { a: 20, b: 30 }; let propName = getPropName(); // returns "a" or "b" let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a
定数はCAPSLOCKで記述し、アンダースコアで区切る必要があります。
定数の名前は特別な形式で記述されます。大文字で、個々の単語の間にはアンダースコアが付きます。
変数が変更されないことを絶対に確信している場合、大文字でその名前を綴ることによってこれを強調できます。 したがって、読者は、どのフラグメントが発生しても、変数は不可侵であることをすぐに理解します。
この規則の重要な例外は、関数内の定数です。 彼らの場合、ラクダケースを使用する必要があります。
// bad const number = 5; // good const NUMBER = 5;
1つの変数-1つの宣言
各ローカル変数には個別の宣言があります。 フォームlet a = 1、b = 2の宣言は許可されません。
// bad let a = 1, b = 2, c = 3; // good let a = 1; let b = 2; let c = 3;
二重引用符ではなく、単一引用符を使用します
標準の文字列リテラルは一重引用符（ '）で区切られ、二重（ "）はこの目的には使用されません。
ヒント：文字列にすでに一重引用符が含まれている場合は、バッククォート付きのテンプレートの使用を検討してください-これにより、フォーマットの問題を回避できます。
// bad let directive = "No identification of self or mission." // bad let saying = 'Say it ain\u0027t so.'; // good let directive = 'No identification of self or mission.'; // good let saying = `Say it ain't so`;
そして最後に
冒頭で述べたように、これを揺るぎない戒めとみなすことは価値がありません。 Googleに加えて、他のIT大手があり、これらのルールはより推奨的な性質のものです。
しかし、この警告があっても、優れたコードを書いている優秀な従業員がたくさんいるGoogleのような会社からのスタイルの推奨は非常に興味深いものです。 「Google製品と互換性のあるソースコード」を記述したい場合は、これらのルールに従うか、単に指を振るだけです。
個人的には、Airbnbの仕様は多くの点でGoogleの仕様よりも魅力的だと思います。 ただし、これらのルールに関してどのような立場をとっても、1つのことを覚えておくことは重要です。スタイル内のコードを扱うときは、一貫性を維持する必要があります。