仕様: フロントエンドコード開発仕様

1. フロントエンド静的コードチェックツール

1.1. ESLint: ESLint は、ルール プラグインまたはカスタム ルールを使用してコードの静的検査を実行できるプラグイン JavaScript コード検査ツールです。

1.2、JSLint: JSLint は、Douglas Crockford によって開発された非常に人気のある JavaScript コード検査ツールで、開発者がコード内の潜在的な問題をチェックするのに役立ちます。

1.3. JSHint: JSHint は JSLint のブランチであり、より柔軟な設定オプションをサポートし、より分かりやすいエラー メッセージを提供します。

1.4、TSLint: ESLint に似た TypeScript コード品質ツールであり、カスタム ルールとプラグインをサポートします。

1.5. Prettier: 複数の言語とエディタをサポートし、コードスタイルを統一するためにコードを自動的に整形できるコード整形ツールです。

1.6. Stylelint: Stylelint は CSS に特別に使用される静的検査ツールで、CSS コードが特定の仕様やスタイルに準拠しているかどうかをチェックできます。

1.7、TypeScript: TypeScript は、大規模で複雑な JavaScript アプリケーションの開発に使用できるオープン ソース プログラミング言語です。型チェック、静的分析、コードヒントなどの機能を提供し、開発者がより堅牢で保守しやすいコードを作成できるようにします。

上記のツールは、コードの品質をチェックし、コードの保守性と読みやすさを向上させるのに役立ちます。プロジェクトの要件に応じて適切なツールを選択することをお勧めします。

2. 以下は、一般的なフロントエンド コード レビュー仕様の一部です。

2.1. コード形式: 読みやすさと保守性を向上させるために、コードは特定の形式に従ってフォーマットされる必要があります。たとえば、スペースを使用してコードを整列させたり、インデントを使用してコード ブロックを示したりします。

2.2. 変数の名前付け: 変数、関数名、定数などは、意味があり、明確で理解しやすく、それらが表す実際の意味と一致している必要があります。

2.3. コメントの指定: コメントはコードに適切に追加する必要があり、コメントはコードの重要な情報を網羅し、多すぎても少なすぎてもいけません。

2.4. テストとエラー処理: コードには十分なエラー処理メカニズムが必要であり、コードの品質を保証するために対応するテスト ケースも備えている必要があります。

2.5. パフォーマンスの最適化: リソースの使用量とロード時間を最小限に抑えるためにコードを最適化する必要があります。たとえば、冗長なコードを回避し、ファイル サイズを削減し、ロード中の並列処理を改善します。

上記は一般的なフロントエンド コード レビュー仕様の一部にすぎませんが、さまざまなフロントエンド フレームワーク、言語、デザイン パターン、その他の関連ドキュメントを参照して、プロジェクトに一致するレビュー仕様を策定することもできます。

3. JavaScript変数の命名規則は以下のとおりです。

3.1. 変数名は文字、アンダースコア (_) またはドル記号 ($) で始める必要があります。

3.2. 変数名には、文字、数字、アンダースコア、またはドル記号を含めることができます。

3.3. 変数名には、if、else、for、function などの JavaScript の予約語を使用しないでください。

3.4. コードを理解し、保守しやすくするために、変数名には意味のある名前を使用する必要があります。

3.5. 変数名はキャメルケースで命名する必要があります。つまり、最初の単語は小文字で、後続の単語の最初の文字は大文字になります (例: firstName)。

let userName;
let num1;
let totalAmount;
let _privateValue;
let $globalVar;

第 4 に、JavaScript は冗長な変数名を回避します。

4.1. 意味のある変数名を使用する: 冗長な変数名を避けるために、意味のある変数名を使用します。
たとえば、
ユーザー名を保存するには、「name」の代わりに「userName」を使用します。
const user = { name: "snow" } を使用し、const user = { userName: "snow" } を使用しないでください。このオブジェクトを使用する場合、user.userName ではなく直接 user.name になります。

4.2. グローバル変数を避ける: グローバル変数を使用すると、変数名の競合や冗長性が生じる可能性があります。コード内でグローバル変数を使用することを避け、代わりに変数を関数またはモジュールに限定することができます。

4.3. スコープの使用: JavaScript では、各関数には独自のスコープがあります。スコープを使用すると、変数名の重複を回避できます。たとえば、関数内で宣言された変数にはその関数内でのみアクセスできるため、変数名の競合や冗長性が回避されます。

4.4. const と let を使用する: 冗長な変数名を避けるには、const と let を使用します。const と let を使用すると、変数のスコープが制限され、コードの安全性と保守性が向上します。

4.5. 命名規則を使用する: コード内で命名規則を使用すると、冗長な変数名を避けることができます。たとえば、キャメルケースやアンダースコアの命名法などを使用できます。

上記の方法により、JavaScript における変数名の重複や競合を効果的に回避し、コードの品質と保守性を向上させることができます。

5. CSS 命名規則 BEM

BEM は一般的に使用される CSS 命名規則で、正式名は Block、Element、Modifier です。

5.1. ブロック: ブロックは、1 つ以上の要素を含む独立した再利用可能なコンポーネントです。ブロックのクラス名には 1 つの文字または単語を使用し、複数の単語を接続するにはハイフン (-) を使用することをお勧めします (例: .menu、.list)。

5.2、要素 (Element): 要素はブロックのコンポーネントであり、ブロックにのみ属することができ、単独で使用することはできません。要素のクラス名は、ブロックのクラス名と単一の文字、単一の単語で構成する必要があります。また、複数の単語はハイフン (-) で接続されます (例: .menu__item、.list__item)。

5.3、モディファイア(Modifier): モディファイアはブロックや要素の特性を高めるために使用され、ステータスやテーマなどを表現するためにも使用されます。モディファイアのクラス名は、ブロックまたは要素のクラス名と 1 つの単語または複数の単語をハイフン (-) で結合して構成する必要があります (例: .menu__item--active、.list__item--disabled)。

BEM 命名規則を使用すると、CSS コードがより読みやすく、保守しやすくなります。同時に、不必要なスタイルの競合を減らし、コンポーネントの再利用性を向上させることもできます。

6. BEM 命名規則に加えて、次のような一般的な CSS 命名規則がいくつかあります。

6.1. OOCSS (オブジェクト指向 CSS): これはオブジェクト指向 CSS 設計手法であり、UI モジュールを独立したオブジェクトとして扱い、スタイルを構造とスキンの 2 つの部分に分解します。通常、構造スタイルはクラス名で定義されますが、スキン スタイルは、.button、.button-red などの接尾辞付きのクラス名で定義されます。

6.2. SMACSS (Scalable and Modular Architecture for CSS): これは、スタイル シートを 5 つのレベル (基礎、レイアウト、モジュール、状態、テーマ) に分解する、スケーラブルでモジュール式の CSS アーキテクチャです。各レベルには、対応する命名規則と構成があります。

6.3. ACSS (アトミック CSS): これはアトミック クラスベースの CSS 設計方法であり、スタイルを単一の属性と値のペアとして定義し、各属性と値のペアはアトミック クラスに対応します。このアプローチにより、スタイルの重複と冗長性が大幅に削減され、スタイル シートの保守性が向上します。

6.4、CSS モジュール: これは CSS をモジュール化およびコンポーネント化する方法であり、スタイル シートをそれぞれ独自の名前空間とローカル スコープを持つ独立したモジュールとして扱い、スタイルの競合を防ぎ、コンポーネントの再利用性を向上させます。

プロジェクトやチームによって適した命名規則が異なるため、自分に合った命名規則を選択すると、CSS コードの保守性と再利用性が向上します。

7. JavaScript の命名セマンティクスに関する提案

JavaScript では、命名セマンティクスは通常、明確で理解しやすく、意味と目的を表現する変数名、関数名、クラス名、その他の記号名のエンコード方法を指します。名前付けセマンティクスに関するいくつかの提案を次に示します。

7.1. 変数名: 変数名は、変数に格納されている内容を正確に説明する必要があり、略語や略語が広く受け入れられている場合を除き、略語や略語は避けるべきです。たとえば、果物には `fruit`、価格には `price` を使用して、 usrNm ユーザー名を表すのではなく、 を使用する必要があります userName

7.2. 関数名: 関数名は関数の目的と機能を正確に説明する必要があり、小文字で始まるキャメルケース命名法と動詞と名詞の形式が理解しやすくなります。たとえば、`calculateTotal` を使用して合計金額を計算し、`displayMessage` を使用してメッセージを表示し、getUserNameユーザー名を取得し、validateEmail電子メール アドレスを確認します。

7.3. クラス名: クラス名は、クラスの目的と機能を正確に説明する必要があります。たとえば、人間を表すには `person` を使用し、乗り物を表すには `Car` を使用します。

7.4. 定数名: 定数名は大文字とアンダースコアで構成され、定数の目的と意味を説明する必要があります。たとえば、最大幅には `MAX_WIDTH`、円周率には `PI` などを使用します。

7.5. 列挙値: 列挙値は大文字とアンダースコアで構成され、列挙値の目的と意味を説明する必要があります。たとえば、赤には `COLOR_RED`、大には `SIZE_LARGE` を使用します。

7.6. ブール値: 変数に true と false の 2 つの値しかない場合は、形容詞または動詞の過去分詞を使用して名前を付ける必要があります。たとえば、可視かどうかを示すには「isVisible」を使用し、完了したかどうかを示すには「isDone」を使用します。

7.7. コールバック関数名: コールバック関数名は、コールバック関数の機能と目的を正確に説明する必要があります。たとえば、操作が成功したときに実行されるコールバック関数を示すには「onSuccess」を使用し、操作が失敗したときに実行されるコールバック関数を示すには「onError」を使用します。

7.8. クラス名には、クラスが表す意味を説明できる、大文字で始まるキャメルケースの命名方法を使用する必要があります。たとえば、ユーザーを表すクラスには という名前を付け User、項目を表すクラスには という名前を付ける必要があります Product

セマンティクスに名前を付けることで、コードの理解と保守が容易になり、コードの可読性と保守性が向上します。

八、jsはオブジェクトの属性値をローカル変数として保存します 

const person = {
  name: 'John',
  age: 30,
  gender: 'male'
};

//推荐
const { name, age, gender } = person;
console.log(name, age, gender);

//不推荐
console.log(person.name, person.age, person.gender);

9、最小機能基準

最小関数原則 (単一責任原則、SRP) は、関数を作成するときに、関数の責任が単一であることが保証される必要があること、つまり、各関数が 1 つのことだけを実行する必要があることを意味します。これにより、関数がよりクリーンで読みやすくなり、保守とテストが容易になります。SRP は、オブジェクト指向プログラミングの基本原則の 1 つです。

SRP に従うと次のようなメリットがあります。

1. コードの可読性と保守性の向上: 各関数は 1 つの責任のみを担当し、コードのロジックがより明確になり、理解と変更が容易になります。
2. コードのテスト容易性の向上: 各関数の役割は 1 つだけであり、より正確なテスト ケースを作成してコードをより堅牢かつ安定させることができます。
3. コードの再利用性の向上: 単一の責任を持つ関数をさまざまなシナリオで再利用できるため、冗長な関数やコードの重複が回避されます。
4. モジュール化とカプセル化の改善: 同様の責任を持つ関数をモジュールまたはクラスに結合して、コードの再利用性と保守性を向上させることができます。

実際のプログラミングでは、次のような SRP に従う方法がたくさんあります。

1. 各関数は複数のパラメーターではなく、1 つのパラメーターのみを処理します。
2. 各関数は 1 つの値のみを返すか、1 つの値のみを変更します。
3. 1 つの機能を複数の機能に分割し、各機能は特定の責任のみを担当します。
4. 機能を複数のステップに分割し、各ステップが 1 つの責任のみを担当し、これらのステップを 1 つの機能に結合します。

10. 関数型プログラミングの使用をお勧めします

以下は、別の関数を引数として受け取り、その関数を配列の各要素に適用し、結果の配列を返す簡単な JavaScript 関数プログラミングの例です。

function mapArray(array, f) {
  var result = [];
  for (var i = 0; i < array.length; i++) {
    result.push(f(array[i]));
  }
  return result;
}

// 定义一个函数,计算一个数的平方
function square(x) {
  return x * x;
}

var numbers = [1, 2, 3, 4, 5];
// 使用函数式编程,将 square 函数应用到 numbers 数组的每个元素中
var squares = mapArray(numbers, square);
console.log(squares); // [1, 4, 9, 16, 25]

mapArray()この例では、配列と関数を引数として受け取り、その関数を配列の各要素に適用し、結果を新しい配列に格納して、新しい配列を返す関数を定義します。 square()数値の 2 乗を計算する関数も定義します 。次に、  mapArray() function と square() function を 使用しnumbers て配列内の各要素の 2 乗を配列に格納し squares 、  console.log() function を使用しsquares てその配列をコンソールに出力します。

11. Vueプロジェクト開発仕様書

11.1、コードスタイル

Vue プロジェクトで eslint を使用して、統一されたコード スタイルを確保します。特定の設定については、 公式 eslint-config-vue ドキュメントを参照してください。

11.2. ディレクトリ構造

コードの編成とメンテナンスを容易にするために、Vue プロジェクトのディレクトリ構造は明確である必要があります。

11.2.1. 基本的なディレクトリ構造

|-- dist                               // 打包后的文件目录
|-- public                             // 公共静态资源文件,如index.html
|   |-- index.html
|-- src                                // 源码目录
|   |-- api                            // 接口请求相关文件
|   |   |-- index.js                   // 请求封装入口文件
|   |   |-- api.js                     // 接口具体实现文件
|   |   |-- ...                        // 其他接口实现文件
|   |-- assets                         // 图片,字体等静态资源文件
|   |-- components                     // 公共组件目录
|   |-- mixins                         // 公共 mixins
|   |-- router                         // 路由文件
|   |-- store                          // Vuex 状态管理文件
|   |-- utils                          // 公共工具函数
|   |-- views                          // 页面组件目录
|   |-- App.vue                        // 根组件
|   |-- main.js                        // 入口文件
|-- .gitignore                         // git 忽略文件
|-- babel.config.js                    // babel 配置文件
|-- package.json                       // 依赖配置文件
|-- README.md                          // 项目说明文件
|-- vue.config.js                      // Vue 配置文件

11.2.2. コンポーネントのディレクトリ構造

|-- components
|   |-- Login
|   |   |-- index.js                   // 组件入口文件
|   |   |-- Login.vue                  // 组件代码文件
|   |   |-- Login.scss                 // 组件样式文件
|   |   |-- Login.spec.js              // 组件测试文件
|   |   |-- Login.story.js             // 组件故事文件

11.3. コンポーネントの命名

Vue コンポーネントの名前は、他の人がコードを理解して使用できるように意味のあるものにする必要があります。

命名規則:

  • すべて小文字の単語
  • 複数の単語の間にはハイフン (-) を使用します
  • 、など、同様の機能を持つコンポーネントには同じプレフィックスを使用することをお勧めします v-button。 v-button-group

vue コンポーネント名の省略形は避けてください。たとえば、 buttonの代わりに 使用しますbtn

11.4. コンポーネントの構造

Vue コンポーネントの構造は明確で、再利用と保守が容易である必要があります。

vue コンポーネントのコード構造は次のように推奨されます。

<template>
  <div class="container">
    <!-- 组件主体内容 -->
  </div>
</template>

<script>
  export default {
    name: 'ComponentName', // vue 组件名称

    props: { // vue 组件属性
      propA: {
        type: String,
        default: 'A'
      },
      propB: {
        type: Number,
        default: 0
      }
    },

    data () {
      return {} // vue 组件数据
    },

    computed: { // vue 计算属性
      computedA () {
        // ...
      }
    },

    watch: { // vue 监听器
      'watchA' (val, oldVal) {
        // ...
      }
    },

    methods: { // vue 组件方法
      methodA () {
        // ...
      }
    },

    // vue 生命周期
    beforeCreate () {},
    created () {},
    beforeMount () {},
    mounted () {},
    beforeUpdate () {},
    updated () {},
    beforeDestroy () {},
    destroyed () {}
  }
</script>

<style lang="scss" scoped>
  .container {
    /* 样式代码 */
  }
</style>

11.5、コードコメント

コードのコメントは保守性と読みやすさにとって非常に重要です。他の人がコードを理解し、変更しやすくするために、コード内にコメントを追加することをお勧めします。

注釈のルール:

  • 異なるセクションを区別するために、コメントの間には空行が残されています。
  • コメントの内容は簡潔かつ明確である必要があり、長すぎないようにする必要があります。
  • コメントコンテンツをコメントされたコードの右側ではなく上に配置します
  • 標準的なネー​​ミングで理解できる場合はコメントを書く必要はありません

11.6. その他

  • コンポーネント スタイルは SCSS を使用して均一に記述されます
  • v-if パフォーマンスに影響するため、併用および 併用は禁止されています v-for 。プロパティを計算する方法を使用することをお勧めします。
  • 変数名、関数名、ファイル名などには意味のある名前を付ける必要があり、 、 などの 1 文字の命名方法は使用しないでください a。 b
  • Vuex 状態管理を使用する場合は、1 つのファイルのコードが 400 行を超えないようにすることをお勧めします。

12. この記事は AI の助けを借りて作成されています。交換および修正、フォロー、一緒に学ぶことを歓迎します。

参考リンク

フロントエンド チームのコード レビュー CheckList チェックリスト - Nuggets

コード仕様書ライブラリをいくつか紹介しますので、収集することをお勧めします。- ナゲット

フロントエンド コード レビュー仕様 - 短い本

おすすめ

転載: blog.csdn.net/snowball_li/article/details/124928488