前回のレッスンで名前付けと注釈について説明しましたが、このレッスンではコード スタイルについて説明します。コード スタイルについて言えば、どちらのスタイルが優れているかを言うのは実際には困難です。最も重要なこと、そして私たちが最も必要としているのは、チームとプロジェクトで統一されたスタイルを維持することです。これにより、コードは同じ人によって書かれ、統一されます。これにより、読み取りノイズが減少し、コードの可読性が向上します。これが私たちが実際に達成したいことです。
コードスタイルに関して、私が特に注目すべきだと思う6つのポイントをまとめましたので、今日は皆さんと一緒に議論し、学んでいきます。
1. クラスと関数の大きさは?
一般的に言えば、クラスまたは関数のコードの行数は多すぎてはいけませんが、少なすぎてもいけません。クラスや関数のコード行数が多すぎる クラスには数千行、関数には数百行が含まれる ロジックが複雑すぎる コードを読むとき、簡単に裏を読んで表を忘れてしまう. 逆に、クラスや関数のコード行数が少なすぎると、総コード量が同じ場合、その分クラスや関数の分割数が増え、呼び出し関係が複雑になります。あるコードのロジックを読んでいると、 n 個の複数のカテゴリまたは n 個の複数の機能の間を頻繁にジャンプする必要があり、読み心地がよくありません。
クラスまたは関数に最適なコードの行数は?
講義 15 で述べたように、正確な定量値を与えることは困難です。その際、料理にも例えますが、「塩少々」の「少々」は料理人でも具体的な量を言うのは難しいです。
関数コードの行数の上限については、インターネット上で、ディスプレイ画面の縦方向の高さを超えてはならないということわざがあります。たとえば、私のコンピューターでは、関数のコードを完全に IDE に表示する場合、コードの最大行数は 50 を超えることはできません。この発言はかなり理にかなっていると思います。複数の画面の後、コードを読み取るとき、前後のコードロジックを接続するために、画面を頻繁に上下にスクロールする必要があるため、読み取りエクスペリエンスが悪いことは言うまでもなく、エラーも発生しやすくなります。
クラスのコード行数の最大制限については、正確な値を与えることはさらに困難です。講義15では、間接的な判断基準、つまりクラスのコードに圧倒され、ある関数を実装する際にどの関数を使えばいいのかわからない場合、どの関数を使いたいかという間接的な判断基準も出しました。長い間検索しても見つかりませんでした. クラス全体を紹介するために小さな関数のみを使用している場合 (クラスには、この関数の実装とは関係のない多くの関数が含まれています)、それはクラスが大きすぎます。
2. コード行の最適な長さは?
Google Java スタイル ガイド ドキュメントでは、コード行は最大 100 文字に制限されています。ただし、プログラミング言語、仕様、プロジェクト チームが異なれば、これに対する制限も異なる場合があります。この制限がどれほどであっても、一般的には、コードの最長行が IDE によって表示される幅を超えてはならないという原則に従う必要があります。行のすべてのコードを表示するには、マウスをスクロールする必要がありますが、これは明らかにコードの読み取りに役立ちません。もちろん、この制限は小さすぎてはいけません。小さすぎると、わずかに長いステートメントが 2 行に折りたたまれてしまい、コードのクリーンさに影響し、読みにくくなります。
3. 空行をうまく利用して単位ブロックを区切る
比較的長い関数の場合、論理的にいくつかの独立したコード ブロックに分割できる場合、これらの独立したコード ブロックを小さな関数に抽出してロジックを明確にするのは不便です。要約コメントを使用する方法に加えて、空白行を使用して各コード ブロックを区切ることもできます。
また、クラスのメンバー変数と関数の間、静的メンバー変数と通常のメンバー変数の間、関数の間、さらにはメンバー変数の間でも、空白行を追加してこれらの違いを作ることができます モジュールのコードの間で、境界がより明確に定義されます. コードを書くことは、記事を書くことに似ています.空白行をうまく使うと、コードの全体的な構造がより明確になり、より整理されたように見えます.
4. 4 つのスペースのインデントまたは 2 つのスペースのインデント?
「PHP は世界で最も優れたプログラミング言語ですか?コード区切りは 4 つまたは 2 つのスペースでインデントする必要がありますか?」これらは、プログラマーの間で最も議論される 2 つのトピックです。私の知る限り、Java 言語はスペース 2 つ、PHP 言語はスペース 4 つにインデントする傾向があります。2スペースインデントにするか4スペースインデントにするかは個人の好みによると思います。プロジェクト内で統一できる限り。
もちろん、別の選択基準があります。つまり、業界が推奨するスタイルと一致すること、および有名なオープン ソース プロジェクトと一致することです。オープン ソース コードをプロジェクトにコピーする必要がある場合、インポートされたコードのスタイルをプロジェクト自体のコードと一致させておくことができます。
ただし、個人的には、スペースを節約するために 2 つのスペースのインデントを使用することをお勧めします。特に、コードの入れ子レベルが比較的深い場合、累積インデントが大きいと、ステートメントが 2 行に折りたたまれやすくなり、コードの可読性に影響します。
さらに、2 スペースのインデントまたは 4 スペースのインデントのいずれを使用する場合でも、インデントにタブ キーを使用してはならないことを強調する価値があります。異なる IDE ではタブ キーの表示幅が異なるため、スペース 4 個のインデントで表示されるものもあれば、スペース 2 個のインデントで表示されるものもあります。同じプロジェクト内で、異なる同僚が異なるインデント方法 (スペース インデントまたはタブ キー インデント) を使用している場合、一部のコードが 2 スペース インデントで表示され、一部のコードが 4 スペース インデントで表示される場合があります。
5. 中括弧は新しい行から始める必要がありますか?
左中かっこは新しい行で開始する必要がありますか? これも物議を醸しています。私の知る限り、PHP プログラマーは新しい行を開始するのが好きで、Java プログラマーは前のステートメントをまとめるのが好きです。具体的なコード例は次のとおりです。
// PHP
class ClassName
{
public function foo()
{
// method body
}
}
// Java
public class ClassName {
public void foo() {
// method body
}
}
個人的には、ブラケットをステートメントと同じ行に置くことをお勧めします。理由は上記と同様で、コード行を節約できます。しかし、新しい行で中括弧を開く方法にも利点があります。このように、左右の括弧を縦に並べることができ、どのコードがどのコードブロックに属しているかが一目瞭然です。
ただし、チームが統一され、業界が統一され、オープンソースプロジェクトに沿っている限り、中括弧は前のステートメントと同じ行にある、または新しい行であることは変わりません。善悪の絶対的な区別はありません。
6. クラス内のメンバーの順序
Java クラス ファイルには、まずクラスが属するパッケージ名を記述し、次にインポートによって導入された依存クラスをリストします。Google Coding Standards では、従属クラスは小さいものから大きいものへとアルファベット順に並べられています。
クラスでは、メンバー変数は関数の前に来ます。メンバー変数間または関数間では、「静的 (静的関数または静的メンバー変数)、通常 (非静的関数または非静的メンバー変数)」のように配置されます。また、メンバー変数や関数の間は、スコープの大きいものから小さいものへと並べていくので、パブリックなメンバー変数や関数は、まずパブリック、次にプロテクト、最後にプライベートと書きます。
ただし、異なるプログラミング言語では、クラスの内部メンバーの配置順序がまったく異なる場合があります。たとえば、C++ では、メンバー変数は習慣的に関数の後ろに配置されます。また、関数間の配置順序は、今述べたスコープの大きさに合わせて配置されます。実は、呼び出し関係のある関数をまとめて配置するという、別の配置の癖があります。たとえば、パブリック関数が別のプライベート関数を呼び出す場合は、2 つをまとめます。
キーレビュー
では、本日の内容は以上です。集中する必要があることをまとめて一緒に確認しましょう。このレッスンでは、コード スタイルの注意点を 6 つのポイントを通してお伝えします。
1. 関数とクラスの大きさは?
関数のコードの行数は、1 画面のサイズ (50 行など) を超えてはなりません。クラスのサイズ制限を決定するのはより困難です。
2. コード行の最適な長さは?
IDE によって表示される幅を超えないようにすることをお勧めします。もちろん、制限は小さすぎてはいけません. 小さすぎると、少し長いステートメントが2行に折りたたまれてしまい、コードのクリーンさに影響し、読みにくくなります.
3. 空行をうまく利用して単位ブロックを区切る
比較的長い関数の場合、ロジックを明確にするために、空白行を使用して各コード ブロックを区切ることができます。クラス内、メンバー変数と関数の間、静的メンバー変数と通常のメンバー変数の間、関数の間、さらにはメンバー変数の間でも、空白行を追加して、異なるモジュールのコード間の境界をより明確にすることができます。
4. 4 つのスペースのインデントまたは 2 つのスペースのインデント?
特にコードの入れ子レベルが比較的深い場合は、スペースを節約できる 2 スペースのインデントを使用することを個人的にお勧めします。さらに、2 スペースのインデントまたは 4 スペースのインデントのいずれを使用する場合でも、インデントにタブ キーを使用してはならないことを強調する価値があります。
5. 中括弧は新しい行から始める必要がありますか?
個人的には、前のステートメントと同じ行に中かっこを置くことをお勧めします。これにより、コード行を節約できます。ただし、中括弧を新しい行に配置することにも利点があります。つまり、左右の中括弧を縦に並べることができ、どのコードがどのコード ブロックに属しているかが一目でわかります。
6. クラス内のメンバーの順序
Google Java プログラミング仕様では、依存クラスは小さいものから大きいもののアルファベット順に並べられています。クラスでは、最初にメンバー変数を記述し、次に関数を記述します。メンバー変数または関数の間には、最初に static メンバー変数または関数を記述し、次に通常の変数または関数を記述し、スコープのサイズに従って順番に配置します。
チームやプロジェクトで統一できる限り、すべてのコーディング スタイルに善悪はなく、業界が推奨するスタイルとコード スタイルに一致することが最善であると、今日は述べました。オープン ソース プロジェクトの。
クラスディスカッション
4 スペースのインデントや 2 スペースのインデントなど、よく知っているプログラミング言語のコーディング スタイルについて話しますか? プロジェクトのプログラミング仕様を整理してみてください。
メッセージエリアに答えを書き留めて、クラスメートとコミュニケーションを取り、共有してください。何かを得た場合は、この記事を友達と共有してください。