カオスから明瞭さへ: React コードをフォーマットしてクリーンで読みやすいコードベースを実現する-jsチュートリアル-php.cn

新しいプロジェクトを開始するとき、React 開発者の間ではよくある経験があります。コードがきれいで読みやすいと満足し始めますが、少数の関数やコンポーネントを作成するだけで、コードベースが徐々に混乱に陥っていくのを観察するだけになります。上から下、左から右にスクロールし、コード行を繰り返し読み、ファイルからファイルへ移動することになります。機能を終了したら、その機能を編集したり変更したりするのはもちろん、単一の関数や変数を見つけるのにどれくらいの時間がかかるかがわかっているので、そのファイルを再度開く必要がなくなることを望みます。

この記事では、コードベースをクリーンで読みやすくする上で書式設定が果たす役割を検討します。また、一貫したフォーマットを実現するための業界標準とベストプラクティスについても説明します。

コードをフォーマットする理由

書式設定は、コードの読みやすさと保守性にとって非常に重要です。しかし、どうやって?

適切にフォーマットされたコードは、コードのさまざまな部分を視覚的に分離するのに役立ち、論理的な流れをたどりやすくなります。適切なインデントにより、親と子のコンポーネント、要素、またはセレクター間の関係が強調表示されます。一貫したフォーマットにより、コードを迅速にデバッグ、修正、保守する能力が強化されます。同じ書式ルールに従うチームメンバーと共同作業する場合、混乱することなく互いのコードを理解することが容易になります。

精神的負担の軽減も、適切な書式設定の利点です。コードがきれいであれば、理解するのに精神的な労力が少なくて済むため、フォーマットが不十分なコードブロックを解読する代わりに、新しい問題の解決に集中できます。

チームが一貫したスタイルに従えば、個人の好みに合わせてコードブロックを再フォーマットする時間を無駄にすることなく、全員が貢献できます。適切なフォーマットは、コードベースに規律とプロフェッショナリズムももたらします。

最後に、ツールの互換性は大きな利点です。開発者は、一貫したフォーマットに依存するリンター、アドオン、IDE を使用します。これらのツールを最大限に活用し、オートコンプリートやエラーの強調表示などの機能を活用するには、コードベースを適切にフォーマットする必要があります。しかし、どうすればそれを達成できるのでしょうか?

コードベースのフォーマットには何が関係しますか?

コードベースのフォーマットについて話すとき、私たちは通常、インデント、行の長さ、命名規則、間隔、中括弧と括弧、引用符の一貫した使用、セミコロンの使用、ファイルとフォルダーの構造、およびコメント。次に、これらがどのように使用および実装されるかについての業界標準について説明します。

インデント
インデントとは、コードを視覚的に階層構造に編成するために空白を使用することです。ここでの業界標準は、2 つまたは 4 つの空白を使用し、タブの使用を避けることです。 JavaScript と React の Airbnb スタイルガイドによると、スペースを 2 つ使用する必要があります。これは、一貫したネストレベルが維持され、コード全体の可読性が向上するためです。
線の長さ
ここでの行の長さとは、1 行に記述しているコードがどのくらいの長さになるかを指します。ここでの業界標準は、1 行を 80 ～ 100 文字にすることです。多くのガイド、特に PEP 8 以降では 80 文字を推奨しています。これは、水平スクロールを防止し、通常はさまざまな画面サイズでも適切に機能するためです。しかし、これはコードを書くときにカウントする必要があるという意味でしょうか?いいえ、少なくとも vscode のようなコードエディターを使用する場合は違います。下の画像は、特定の行に何文字あるかを確認する方法を示しています。下の画像は、44 行目で 93 文字目であることを示しています。デフォルト設定を変更していない場合は、vsCode エディターの右下にあります。

From Chaos to Clarity: Formatting React Code for a Clean and Readable Codebase

命名規則

これは、一貫した方法で命名するための一連のルールを指します。読みやすく、理解し、保守しやすいコードを作成するには、明確で意味のある正確な命名が不可欠です。変数と関数の最も一般的な命名規則は、次のとおりです。キャメルケース (スペースを使用せず、各単語の最初の文字を大文字にすることでフレーズ内の単語を区切る方法)。 React コンポーネントの場合は、React ドキュメントに記載されているようにコンポーネントの最初の文字は大文字にする必要があるため、特に PascalCase を使用する必要があります。また、定数については大文字のスネークケースが推奨されます。このセクションでは命名を正しく行っていません。命名について詳しく説明するならここでこの記事は長くなりすぎます。さらに詳しく知りたい場合は、命名規則に関するこの記事を参照してください。
間隔
特に特定の演算子を組み合わせて使用すると異なる演算が実行されるため、「間隔」では、わかりやすくするために演算子の周囲にスペースを追加することをお勧めします。コードの論理セクションを区切るために空行を使用することもお勧めします。空白行を使用してグループ化し、関数宣言とロジックから変数宣言と代入を試みます。
中括弧と括弧
Airbnb スタイルガイドによると、ぶら下がり中括弧があってはなりません。つまり、すべての閉じ中括弧または括弧を、対応する開き中括弧または括弧と適切に揃える必要があります。
一貫した引用
引用符を使用する場合は、プロジェクト全体で単一引用符 '' または二重引用符 "" を使用し、両方の不必要な組み合わせの使用を避けることをお勧めします。
セミコロン
引用符の場合と同様に、式、代入、コード行の終了にセミコロンを使用するか、セミコロンをまったく使用しないかを決めますが、どのような決定であっても、それに固執して一貫性を保つようにしてください。個人的には、自動セミコロン挿入に伴う問題を回避するためにセミコロンの使用をお勧めします。
ファイルとフォルダーの構造
ファイルとフォルダーの構造については、プロジェクトのサイズや技術スタックなどの要素が主にファイルとフォルダーの構造を決定しますが、従うべき一般的なルールが 2 つあります。 1 関連ファイルをグループ化します。 2 意味のあるファイル名を使用します。
コメント
コードベースはコードで簡単にクラスタ化される可能性があるため、コメントを多用して状況を悪化させないでください。適切な命名規則を持ち、アンチパターンのないクリーンなコードを記述している場合は、通常はコメントの使用を避けることができるはずです。ロバート・C.のように。 Martin 氏は、「コメントは本質的に悪いものではない」が、多くの場合「コード自体で意図を表現できていないことの表れ」であると述べています。コメントはコード内に必ず存在します。コメントは、コードのブロックがどのように機能するかではなく、コードが存在する理由を示します。したがって、コードに自明ではない決定や回避策が含まれる場合は、コメントを使用する必要があります。そのため、コードの仕組みを説明する必要をなくすため、またコードがすでに表現している内容の説明を避けるために、アンチパターンを避けてください。