過去 5 年間、私はコーディング スキルを向上させるために常に努力してきました。その 1 つは、最も推奨されているコーディング スタイルを学習して従うことでした。
このガイドは、一貫性のあるエレガントなコードを作成できるようにすることを目的としており、コードの読みやすさと保守性を向上させるためのアドバイスが含まれています。これは、コミュニティ内で最も受け入れられている一般的なガイドラインに触発されていますが、私の好みに合わせていくつかの修正が加えられています。
私はフルスタックの JavaScript 開発者であり、私のメモはすべて私の技術スタック (MEVN) に固有のものであり、他のスタックには適用できない可能性があることを言及しておく価値があります。

一般規則

コードの重複を避ける

同じコード ブロック (または管理可能な違いはある) を複数の場所に記述する必要がある場合、それらを関数にマージすることが不可欠であり、今後は常にその関数を呼び出すようになります。必要です。

疎結合を考慮する

関数は独立して動作する必要があります。つまり、入力と出力が同じである限り、ある関数を編集しても他の関数には絶対に影響を及ぼしません。各関数は、他の関数の定義について知識を持たず、別個のコンポーネントとして動作する必要があります。この状況では、知っているのはそのパラメーターだけであり、誰が関数を呼び出しても、同じ入力は常に同じ結果を返します。

宣言

まず第一に、常に変数を宣言することを忘れないでください。
変数を再割り当てしない場合は、const キーワードを使用します。ただし、ネストされた要素を再割り当てする予定がある場合でも、オブジェクトまたは配列である変数に対して const を使用することはできます。
モジュールを要求し、常に const キーワードを使用して定数変数を定義することに注意してください。
const を使用できない場合は let キーワードを使用し、古いブラウザをサポートする必要がある場合にのみ var キーワードを使用します。

機能

関数は次のものに制限する必要があります:

• 4 つの変数
• 4 つのパラメータ
• 30 行のコード (コメントを無視)
• 4 つの分岐 (if-else、while、for、or-and、switch-case)

コード行は 100 文字に制限する必要があり、関数をグループ化/整理するには、関連する関数をできるだけ近くに配置することをお勧めします。
可能な場合は常に、アロー関数の構文を従来の代替関数に特権化します。

文字列

通常の文字列リテラルには (二重引用符 " ではなく) 一重引用符 ' を使用しますが、埋め込み変数/式を含む文字列、複数行の文字列、および一重引用符文字を含む文字列の場合は、テンプレート リテラルを使用します。

ネーミング

変数に名前を付けるときは、一貫性を維持することが重要です。これは、異なるページ上の変数が同じデータを担当する場合、それらの変数は同じ名前を持つ必要があることを意味します。

変数、関数、メソッド、およびパラメーターの名前は、それ自体がわかりやすいものである必要があります。つまり、名前を見るだけで、含まれているデータについて誰でも知ることができる (または少なくとも公正な推測ができる) 必要があります。

定数変数は大文字にし、単語をアンダースコアで区切る必要があります。関数、変数、メソッドはキャメルケース構文に従う必要がありますが、CSS クラスと ID はケバブケース構文に従う必要があります。

コメント

コメントは常に大文字で始まり、100 文字に制限されます。コード行は同じルールに従うことを覚えているかもしれませんが、行に両方が含まれる場合、最大 150 文字しか超えられないことに注意してください。
関数を説明するコメントは、関数が呼び出される場所ではなく、関数が定義される場所に記述する必要があります。

行の長さが 150 文字を超えない限り、コメントは 1 行のコードの後に​​配置します。このような場合、および複数行のコードの場合は、コメントを先頭に置きます。

if文に関しては、コメントは条件文の後に記述してください。

if (conditionIsTrue) { // Put your comment here
    doSomeThing();
} else { // Put your comment here
    doSomethingElse();
}

1 行のコメントには二重スラッシュ // を使用し、複数行のコメントには /* */ を使用することを忘れないでください。複数行のコメントを 1 行のコードまたは条件文に追加する場合は、/* がコードの前に記述され、コメントが次の行から始まり、*/ が新しい行に記述されるように、コメントを /* */ 内に配置します。ライン。

if (conditionIsTrue) { /*
        Put your comment here
        Put your comment here
    */
    doSomeThing();
}

functionName(parameter), /*
    Put your comment here
    Put your comment here
*/

機能説明コメント

/** */ で囲まれた関数の上にコメントを配置します。

• @param {type} 変数名の説明を使用してパラメータを記述します。
• パラメータが複数の変数の型を受け入れることができる場合は、 @param {type1 | を使用します。 type2} 変数名の説明.
• パラメータがオプションであり、省略できる場合は、@param {type} [variableName] description を使用します。
• パラメータにデフォルト値がある場合 (実際にデフォルト値を持つにはオプションである必要があります)、@param {type} [variableName="value"] description を使用します。
• @returns {type} の説明を使用して関数の出力を記述します。

/**
 * Describing the function here
 * @param {type} normalVariable A normal variable
 * @param {type1 | type2} multiTypeVariable A variable with multiple expected types
 * @param {type} [variableWithDefaultValue="value"] An optional variable that has a default value in case of being absent when calling the function 
 * @param {type} [optionalVariable] An optional variable
 * @returns {type} description
*/
const functionName = (normalVariable, multiTypeVariable, variableWithDefaultValue, optionalVariable) => {
    doSomeThing();
}

reqパラメータとresパラメータを持つサーバー関数については、リクエストパラメータを記述する必要はありません。 @returns description.
を使用して応答のみを記述します。

/**
 * Describing the function here
 * @returns description
 */
functionName = (req, res) => {
    doSomeThing();
}

通常、req、res、next、to、from パラメータを記述する必要はありません。

HTML ファイルでは、 を使用してコードの異なる部分を区切ります。したがって、ユーザーは各部分を簡単に識別できます。

コード行の途中にコメントを記述する場合は、/* */.
を使用します。

const calc_result = (firstNumber * secondNumber)/* Explain the reason for the multiplication */   thirdNumber;

インデント

末尾の空白は禁止されています。
式、演算子、記号の前後や、行の最後の文字が ではない の場合は、カンマや中括弧の後にも常にスペースを入れることを忘れないでください。
空行は、ファイルの末尾 (すべてのファイルは空行で終わる必要があります)、最後にインポートされたモジュールの後、Template、Script、および Style タグの区切り、および CSS ルール セットの間でのみ許可されます (また必須です)。
インデントには Tab を使用し、位置揃えには Space を使用することを忘れないでください。

注文

• マングース スキーマの変数とコンポーネントの Vue Reactive State をアルファベット順に並べますが、残りの時間は行を最短から最長の順に並べます。
• ルート メソッドを put、get、post、delete の順序で並べますが、それぞれのメソッド自体はアルファベット順であり、すべてのルートは URL に基づいてグループ化する必要があります。

まとめ

明らかに、これらはこれまでで最高のアドバイスではありませんが、クリーン コードの原則を学ぶことに興味がある人にとっては確かな出発点となると思います。
さらに、これらのルールを厳密に遵守することは、最初は難しいように思えるかもしれませんが、実践するとはるかに簡単になります。

長期的なコードベースに取り組む場合は、たとえ不十分であっても、現在のプロジェクトのガイドラインに従う必要性を強調することが不可欠です。プロジェクトのガイドラインを再検討することに真剣に取り組んでいる場合は、最も有益な変更を検討し、それらを徐々にプロジェクトに注入してください。

カバー画像クレジット: Pexels の luis gomes による写真