コーディング標準は主に、プロジェクト開発者がプログラミング時に従うべき一貫した形式を持てるように、開発チームにプログラミング ガイドラインを提供します。これにより、開発チームの各プログラマが書いたコードを他のプログラマが理解できるようになり、コードの保守性が向上し、複数人で書いた一連のソフトウェアがまるで一人で書かれたかのようになり、コードの作成が容易になります。理解すること。そのためには、全員が一貫したコーディング スタイルを使用する必要があります。 これらの標準を導入するのが決まり文句である理由は、新しい開発者がプロジェクト開発チームに参加するときに、Delphi のコーディング標準に慣れていない人がいる可能性があるためです。 ここでは、これらの標準を次のカテゴリに分けて紹介します。 1. 一般的なソース コード形式の規則 2. プロシージャと関数 3. ファイル、フォーム、およびデータ モジュールの名前付け 4. パッケージとコンポーネントの名前付け 一般的なソース コード形式の規則 インデントはレベルごとに 2 つありますそれらの間のスペース。ソース コードにタブ文字を配置しないでください。これは、タブ文字の幅が設定やコード管理ユーティリティ (印刷、ドキュメント、バージョン管理など) によって異なるためです。マージン マージンは 80 文字に設定されます。ソースコードは通常、単語を書いてもマージンを超えることはありませんが、このルールはより柔軟です。可能な限り、1 行より長いステートメントはカンマまたは演算子で囲む必要があります。改行の後は 2 文字分インデントする必要があります。括弧では、開始括弧と次の文字の間にスペースがありません。同様に、右括弧と前の文字の間にスペースはありません。次の例は、正しい空白文字と間違った空白文字を示しています。 CallPROcedure(Parameters); // 間違っています! CallProcedure (Parameters); // 正しいです! 予約語とキーワード Pascal 言語の予約語とキーワードは常に完全に小文字です。 begin...endbegin ステートメントは単独の行になければなりません。たとえば、以下の最初の行は間違っていますが、2 行目は正しいです。 for i:=0 to 10 do beginStatement end// 間違っています。begin は for i:=0 to 10 do と同じ行にあります。 // 正しい! begin in 別の行の beginStatementend におけるこのルールの特殊なケースは、begin が else ステートメントの一部である場合です。例: if Condition thenbeginStatement endelse beginStatement; endend ステートメントは常に別の行にあります。 begin が else ステートメントの一部ではない場合、対応する end ステートメントは begin ステートメントと同じ量だけインデントされます。ステートメント (1) if_then_else ステートメントの最も可能性の高い状況は then 節に配置し、可能性が低い状況は else 節に配置する必要があります。多くの if ステートメントを避けるには、代わりに case ステートメントを使用します。レベルが 5 つを超える場合は、if ステートメントを使用しないでください。代わりに、より明確な方法を使用してください。 if ステートメントでは余分な括弧を使用しないでください。ソースコードでは、括弧は本当に必要な場合にのみ使用されます。例: if (I=42) then // 間違っています、括弧は冗長です if (I=42) または (J=42) then // 正解、括弧を使用する必要があります if ステートメントでテストする条件が複数ある場合は、計算の複雑さの順に右から左に並べる必要があります。これにより、コードはコンパイラの短絡推定ロジックを最大限に活用できるようになります。 Condition1 が Condition2 より高速で、Condition2 が Condition3 より高速な場合、if ステートメントは次のように構成する必要があります。 if Condition1 および Condition2 および Condition3 then(2) case_else ステートメント case ステートメント内の各ケースの定数は、数値またはアルファベット順に配置する必要があります。注文。各状況のアクション ステートメントは短く、通常はコードが 4 ～ 5 行以内である必要があります。アクションが複雑すぎる場合は、コードを別のプロシージャまたは関数に配置する必要があります。 case ステートメントの else 節は、デフォルトのケースまたはエラー検出にのみ使用されます。 (3) while ステートメントでは、while ループを終了するために exit プロセスを使用しないことを推奨しています。必要に応じて、ループ条件を使用してループを終了する必要があります。 while ループを初期化するすべてのコードは while エントリの前に配置する必要があり、無関係なステートメントで区切るべきではありません。ビジネスのための補助的な作業は、サイクルの直後に実行する必要があります。 (4) for文 ループ回数が決まっている場合は、while文の代わりにfor文を使用します。 (5)repeat 文repeat 文は while ループに似ており、同じ規則に従います。 (6) with 文 with 文の使用には注意が必要です。特に with ステートメント内で複数のオブジェクトまたはレコードを使用する場合は、with ステートメントの過度の使用を避けてください。たとえば、Record1、Record2 を使用すると、これらの状況はプログラマを混乱させやすく、デバッグを困難にする可能性があります。構造化例外処理例外処理は、主にエラーを修正し、リソースを保護するために使用されます。これは、リソースが割り当てられている場合はどこでも、リソースが確実に解放されるように try...finally を使用する必要があることを意味します。ただし、ユニットの最初/最後の部分、またはオブジェクトのコンストラクター/デストラクターでリソースが割り当て/解放される場合は例外となります。 (1) try...finally の使用法 可能な限り、各リソースの割り当ては try...finally 構造と一致する必要があります。例: //次のコードはエラーを引き起こす可能性があります SomeClass1: = TSomeClass.Create;SomeClass2: = TSomeClass.Create;try{do some code}finallySomeClass.Free;SomeClass.Free;end;//上記のリソースに対する安全な解決策割り当ては次のとおりです: SomeClass1: = TSomeClass Create;trySomeClass2: = TSomeClass Create;try{コードを実行}finallySomeClass2.Free;end;finallySomeClass1.Free;end;(2) Try...Except の使用法 例外が発生したときにいくつかのタスクを実行したい場合は、try...Except を使用できます。通常、単にエラー メッセージを表示する場合を除き、try... を使用する必要はありません。これは、アプリケーション オブジェクトがコンテキストに基づいて自動的にこれを行うことができるためです。句でデフォルトの例外処理をアクティブにする場合は、例外を再度トリガーできます。 (3) try...excel...else を else 句とともに使用することはお勧めできません。これは、処理する準備ができていない例外を含むすべての例外がブロックされるためです。