JavaScript、勝利のスタイル

1つのスタイルで記述されたコードには多くの利点があります。マイナーエラーが少なく、多くのエラーはほとんどすぐに検出しやすく、他のエラーは開発段階で簡単にデバッグできます。 しかし、新しいプログラマーはコードを勉強するのに余分な時間を費やす必要はありません(これは、コード自体を理解する必要がないという意味ではなく、読みやすいということだけです)。
チーム全体が所定のスタイルを順守している場合にのみ、コードの品質が向上します。 一般的なルールの開発に時間を費やすことは間違いなく価値があります。
「Pythonコードのスタイルガイド」という単一のルールセットがあるPythonとは異なり、JavaScriptにはありません。 ただし、選択できる一般的なガイドは6つあります。
ガイドに加えて、たとえばJSLintやJSHintなどの自動コードアナライザーも忘れないでください。 そして、彼らはすでに独自の設定を持っています。
問題は、関連性があり、ほとんどの推奨事項に最も対応するJavaScriptコードを記述する最も正しい方法は何ですか? この記事のほとんどの推奨事項を組み合わせて、コードの品質をチェックするプロセスを最適化する方法を考えてみましょう。
クリアランス
くぼみ
- 2つのスペース、タブなし、タブなし:Google、npm、Node.js、Idiomatic
- タブ:jQuery
- 4スペース:クロックフォード
引数と式の間のスペース
多くのガイドは、行末にスペースがないことを思い出させます(末尾のスペース)
行の長さ
- 最大80文字:Google、npm、Node.js、Crockford
行を折り返す場合、インデントは2である必要はありません。たとえば、関数の引数を次の行に転送する必要がある場合は、最初の引数がある場所に揃えることができます。 別のオプションとして、長い行を折り返すときに2ではなく4つのスペースを使用することもできます。
- マイナーな意見:jQuery、慣用的
セミコロン
- 常にセミコロンを使用します:Google、Node.js、Crockford
- 状況によっては使用されない:npm
- マイナーな意見:jQuery、慣用的
コメント:
- JSDoc :Google、慣用的
- Idiomatic Style Guideでは、より簡単なコメントも許可されますが、JSDocが推奨されます
- マイナーな意見:npm、Node.js、jQuery、Crockford
引用
- 単一引用符が望ましい。
'value'
よりも"value":
方が優れてい'value'
"value":
Google、Node.js - 二重引用符 ":jQuery
- マイナーな意見:npm、慣用句、Crockford
変数宣言
- 1行に1つの変数:Node.js
var foo = ''; var bar = '';
- 例のように、行末でコンマで区切られたいくつかの変数:Idiomatic、jQuery
var foo = "", bar = "", quux;
- 行頭のカンマ:npm
var foo = "" , bar = "" , quux;
- マイナーな意見:グーグル、クロックフォード
ブラケット
グローバル変数
- グローバル変数を使用しないでください:Google、Crockford
Google:
グローバル名の競合はデバッグが難しく、2つのプロジェクトを統合しようとすると難治性の問題を引き起こす可能性があります。 共通のJavaScriptコードを共有できるようにするために、衝突を防ぐための規則を採用しました。
翻訳:
グローバル変数はデバッグするのがより難しく、2つのプロジェクトを統合する必要がある場合、それらは重大な問題の原因になる可能性があります。 互換性のあるコードを配布できるように、コーディングスタイルの規則を採用しています。
- Crockfordは、グローバル変数をまったく使用すべきではないと考えています。
- マイナーな意見:慣用的、jQuery、npm、Node
名前
変数
定数
機能
配列
- 単語の複数形を使用してください:慣用
var documents = [];
- マイナーな意見:Google、jQuery、npm、Node、Crockford
オブジェクトとクラス
その他
複数の複合ファイル名と設定にはall-lower-hyphen-css-caseを使用します:npm
JSHintおよび.jshintrcファイルを使用する
JSHintは、コード内のエラーを指摘するコードアナライザーです。 広く使用されている多くのテキストエディターと互換性があります。 また、スタイルの統一とコードの整合性を維持するための良い方法です。
ドキュメントにはさまざまな用途があり
ます 。 以下に、上記のすべての推奨事項に従う.jshintrcファイルの例を示します。 このファイルをプロジェクトのルートフォルダーに配置します。JSHintプラグインがインストールされている場合、エディターは定義したルールに従ってコードをチェックします。
{ "camelcase" : true, "indent": 2, "undef": true, "quotmark": "single", "maxlen": 80, "trailing": true, "curly": true }
ブラウザによって処理されるすべてのファイルに、次を追加します。
Node.jsファイルに以下を追加します。
すべてのタイプのJSファイルでは、以下を追加することをお勧めします。
'use strict';
これはJSHintとJavaScriptハンドラーの両方に影響し、エラー耐性は低下しますが、より高速に動作します。
「厳密な使用」について詳しく読む (外部リンク)
git commitの前にJSHintコードを自動的に確認する
すべてのJSファイルがテストに合格し、.jshintrcで定義した一般的なスタイルに従うことを確認したい場合。 次に、これらの行を
.git / hooks / pre-commitファイルに追加します。 これで、変更をコミットする前に、スクリプトは変更されたファイルのみをチェックして、コードスタイルの違反をチェックします。 そして、もしあれば、操作は中断されます。
追伸
(元の記事)を読んだ人の要求で、
Gitリポジトリが作成され、誰でも.jshintrcまたはドキュメントに変更を加えることができます。
翻訳者から:
私は元の記事の著者を個人的に知っており、翻訳に変更を加えるためのゴーサインを受け取りました。 特に深刻な翻訳の誤りやエラーについては、お好きな方法でお知らせください。 おそらく最も熟練した翻訳ではないかもしれませんが、最後まですべてを読んでくれた人たちに感謝しました。
元の記事: (http://seravo.fi/2013/javascript-the-winning-style)