Delphi コーディング標準

Delphi コーディング仕様 作成者：Tulipsys 更新日：2003年12月16日 目次 １． 一般的な規則（命名 - インデントとスペース - マージン - 大文字と小文字 - コメント） 2. 文(begin...end文-if文-case文-for文-while文-repeat文-with文-例外処理文) 3． 手続きと関数（命名と形式・仮パラメータ・変数・型・カスタム型） ４． オブジェクト指向 (クラスの命名とフォーマット、フィールド、メソッド、プロパティ、メソッドの実装) に関連するコーディング標準を策定する目的は、プログラマーのグループが同じスタイルのコードを生成できるようにして、チームがコーディング標準を形成および維持できるようにすることです。あるスタイル。この目標が達成されれば、プロジェクトのファイル全体がプログラマーによって書かれたように見えます。優れていることは楽しいことですが、利点は、各プログラマーのコードが他の人にとって理解しやすいことであり、これによりコードの保守性が大幅に向上し、保守コストが削減されます。これはどのチームにとっても理想的な状況です。個人の場合、コーディング規範を選択または自ら生成し、この規範に従うことでも良い結果が得られる可能性があります。ちなみに、これは非常に魅力的な目標ですが、達成するのはそれほど難しいことではありません。それぞれのプログラミング言語には独自のコーディング標準があり、コーディング標準は他のプログラミング言語の標準からも学ぶ必要があります。したがって、他の人から学ぶことが非常に重要です。第二に、コーディング標準の使用はプログラマーの作業を簡素化することです。「簡素化」の意味は、コードの量を減らすことではなく (逆に、多くの場合、標準に従うとコードの量が増えます)、プログラマーの作業を減らすことです。コードの量を維持するのに労力がかかります。プログラミングは非常に複雑な仕事であり、さまざまな関係に対処するのは気が遠くなります。さまざまな関係が密接に関係しています。プログラマーは、エネルギーのほとんどを人間関係の処理に費やし、あまりにも詳細な問題に時間を浪費しないようにする必要があります。プログラムの考え方や構造が一目で理解できれば、保守計画もすぐに立てることができます。さらに、コーディング標準は、参照したり変更したりできる非常にユーザーフレンドリーな標準である必要がありますが、使いやすいものでなければなりません。ただし、グループでは、全員が同じ基準を使用するようにしてください。プログラミングは非常に柔軟な仕事であり、柔軟な思考と柔軟な適用があって初めて良い結果が得られます。さらに、仕様の使用は主にプログラマのメモリ負担を軽減するために行われます。人間の思考能力は非常に優れていますが、記憶力は非常に貧弱です。私たちは一日中コンピューターと向き合っていますが、コンピューターが私たちを助けたいと考えている最も重要なことは記憶力です。したがって、プログラマーの思考力の利点を最大限に活用することが私たちの目標の 1 つです。最後に、プログラミング ツールはコーディング標準に大きな影響を与えますが、この影響は開発者のプログラミング スタイルからもたらされます。また、C++ に基づいているため、Microsoft Visual C++ と Borland C++ Builder ではまったく同じコーディング仕様を使用しません。 Microsoft と Borland は、異なる非常に独特なスタイルを持っています。ユーザーとして、これに基づいて変更を加えることができますが、制限があります。実際、ベンダーや開発ツールを選択するとき、将来のスタイルも決まります。 1. 一般的な規則 1.1 命名 命名の基本原則は、名前がデータの機能を明確に表現することです。 Object Pascal は長いファイル名をサポートしています。名前には動詞、名詞、またはその両方の組み合わせを使用する必要があります。 Delphi で定義された予約語やキーワードは使用しないでください。また、他の言語で定義された予約語やキーワードも使用しないようにしてください。完全な単語を使用するようにし、略語、接頭辞と接尾辞、アンダースコア、その他のハンガリー語の命名法は避けてください。名前を読みやすくするために、命名規則が使用されます。ハンガリーの命名法に代表される命名標準は、データのタイプ、範囲、またはその他のさまざまな属性を示すために多くの接頭辞と接尾辞を開発しました。 Delphi では、確かにこの方法を使用できますが、これは推奨される方法ではありません。 1 つの理由は、この種の命名規則によって追加のメモリ タスクが多すぎるためであり、もう 1 つの理由は Delphi 自体の特性によって決まります。 Delphi の必須の型チェックでは、すべての変数の使用状況が自動的に監視されるため、苦労してさまざまな接頭辞を追加する必要がなく、少し注意を払うだけ (単語の大文字化に注意する) だけで済みます。さらに、データは種類や範囲ではなく意味に基づいて検討する必要があり、プログラムの構造、論理的関係、設計思想に注意を払う必要があります。したがって、Delphi では、名前を付けるために単語の完全な組み合わせのみを使用する必要があり、他には何も考慮する必要はありません。もちろん、名前はできるだけ簡潔にする必要があります。一部のステートメント (for ループなど) では、カウント変数として複数の整数を使用する必要があります。ここでは、単純に i、j、k の 3 文字を変数名として使用できます。これは Fortran 言語で開発され保持されてきた習慣であり、非常に便利で理解しやすいことが証明されています。もちろん、MyCounter など、より意味のある名前を使用すると、より良い結果が得られます。一般に、i、j、k の 3 つの文字で完全に十分ですが、それ以外の場合は、さらに多くのプロセスまたは機能を分割する必要があります。以下にいくつかの例を示します。 1. SongsList // これが曲のリストであることを示します。 複数の曲は複数の曲があることを示します。 2. SetCarColor // これが色を設定する関数であることを示します。 TCar クラスが定義されている場合、SetColor は車の色を設定する関数メンバーとしてクラスで使用されます。ブール変数の名前にも注意してください。ブール変数の名前は、True と False の意味を明確に示す必要があります。たとえば、ファイルが存在するかどうかを記録する変数の場合、FileExisted を使用するよりも IsFileExisted を使用する方が適切です。最後に、グローバル変数に Temp または Tmp という名前を付けないでください。ただし、プロシージャまたは関数内では引き続き使用できます。実際、このルールについては多少の議論があります。一部のコーディング標準では、プロシージャや関数であっても、そのような名前付けは絶対に禁止されています。ただし、多くの場合、特にプロシージャや関数の場合、この名前付けは非常に便利です。グローバル変数として使用する場合、型と一致しない代入文が存在する可能性があります。この時点ではコンパイラが多くの支援を提供しますが、小さなエラーの発生を避けることは困難です。 。要約すると、このルールに従うとより良い結果が得られますが、必要に応じて厳密に従う必要はありません。 1.2 インデントとスペース 各レベルの間に 2 つのスペースをインデントする必要があります。これにより、プログラムが明確になり、整理されます。タブ文字の幅はさまざまな設定やアプリケーションで一貫性を維持することが難しいため、タブ文字は決して使用しないでください。ただし、プログラムが Delphi でのみ表示されることを期待しないでください。 Delphi のみを使用する場合は問題ありませんが、Word などのテキスト プロセッサを使用する場合は、各文字と記号の幅を確保するために適切なフォントを使用するように注意してください。同じです。 Word などのテキスト プロセッサで印刷する場合は、フォントの選択にも注意する必要があります。スペースを使用するのは、プログラムをクリーンに保ち、プログラマがプログラムの構造をすぐに理解できるようにするためでもあります。以下にいくつかの仕様と対応する例を示します。 1. 各単語の間にはスペースが必要です。例: TMyClass = class(TObject)2． 「=」、「<>」、「">=」、および「<=」の周囲にはスペースが必要です。「:=」と「:」の右側にはスペースが必要ですが、左側にはスペースが必要です。例: a = b の場合、a:= b; 整数 3。 予約語およびキーワードと左側の記号の間にはスペースが必要ですが、右側の記号との間にはスペースがあってはなりません。例: PROcedure ShowMessage オーバーロード;4. 括弧の使用: プロシージャと関数の定義と呼び出しでは、括弧と外部の単語および記号の間にスペースを入れてはいけません。また、括弧と内部の単語の間にスペースを入れてはいけません。 if文の条件判定では、andやorなどの予約語の間にスペースを入れてください。例: function Exchange(a: integer; b: integer); if (a = b) and ((a = c) or (a = d)) then … end;1.3 margin Delphi エディタは右から 81 番目くらいにあります。実際、Delphi のデフォルトのインターフェイスでは、解像度が 800*600 の場合、最大化されたウィンドウは文字の 4 文字左に表示されます。したがって、濃い線の外側にソース コードを記述しないでください。つまり、各行は先頭と中間のスペースを含めて 80 文字を超えてはなりません。ステートメントが長すぎる場合は、改行が完了し、改行を 2 文字インデントする必要があります。これも印刷が簡単で、Delphiでは暗線より先の部分は印刷されません。 Word などのワープロ ソフトウェアを使用して Delphi プログラムを印刷すると、余分な部分が次の行の先頭に移動され、印刷されたプログラムが読みにくくなります。したがって、この種の作業を印刷に任せずに、コードを作成しながらすべての調整を行うようにしてください。行を折り返すときは、プログラムの可読性の維持に注意し、完全な部分を保持するようにしてください。たとえば、関数が長すぎる場合は、データ型宣言だけでなく、完全なパラメーターの説明をラップします。以下の最初の 2 つの書き方は正しく、次の書き方は間違っています: function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger;e: integer): //正しい function AdditonFiveInputNumber; (a: 整数;b: 整数;c: 整数;d: 整数;e: 整数): 整数; //正しい関数AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger; e: integer; //エラー関数 AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: integer;e: integer ): 整数; //エラー関数 AdditonFiveInputNumber(a: 整数; b: 整数; c: integer; d: ineger;e: integer): integer; //エラー 1.4 カスタム名の各単語の最初の文字は大文字と小文字にする必要があり、他の文字は小文字にする必要があります。 Delphi の予約語とキーワードはすべて小文字にする必要があります。 Delphi 定義関数の記述方法は、カスタム名の記述方法と同じです。 Delphi の基本データ型は小文字にする必要があり、拡張クラス型の最初の 2 文字は大文字にする必要があります（クラス型の最初の文字は「T」です）。例をいくつか示します。 1. カスタム名: MyFavouriteSong、CarList; 2. 予約語: if (a = b) and ((a = c) or (a = d)) then … end; 3. Delphi の事前定義関数 :ShowMessage ('すべて問題ありません');4. Delphi 拡張クラスの種類: MyStrings = TStrings.Create;1.5コメント Delphi は、ブロック コメント ({}) と単一行コメント (//) の 2 種類のコメントをサポートしています。コメントの目的は、プログラムの設計上のアイデアを説明し、プログラマが 2 年前、あるいは昨日書いたプログラムのアイデアをできるだけ早く理解できるようにすることです。これは実は、記憶力の問題を解決するためであり、プログラミングにおいて脳を過度に使用せず、できるだけ言葉を使用する必要があります。したがって、コメントはプログラミング言語において非常に重要な要素ですが、多くの人 (特に初心者、かなりの数のプログラマーを含む) はこれを気にせず、めったにコメントを書きません。コメントのもう 1 つの応用例は、プログラムのデバッグ段階です。たとえば、2 つのステートメントがあり、どちらが良いか事前にわからない場合は、テストする必要があります。ステートメントの前に「//」を置きます (つまり、変更します)。コメントするステートメント)、別のステートメントを実行し、その逆のことを行うと、簡単に選択できます。複数のステートメントの場合はブロックコメントを使用しますが、「{」と「}」は上下に別の行など、目立つ位置に必ず配置してください。以下にいくつかの使用原則を示します。 1. ほとんどの場合、カスタム変数と型の前にコメントを配置する必要があります。 2. ほとんどの場合、ユニット ファイルの先頭にコメントを配置する必要があります。ここでのコメントには、ファイル名、作成日、変更日、作成者、変更者、必要な説明が含まれます。 3. コメントは意味のあるものである必要があり、無駄なコメントは使用しないでください。例: while i < 8 dobegin … i:= i + 1; // iend に 1 を追加; ここではコメント「// i に 1 を追加」は意味がありません (次のような単純なステートメントを意味します)。 i : = i + 1) コメントは必要ありません。多くの場合、単純なステートメントが非常に重要な役割を果たすため、このステートメントが人々に疑問を抱かせたり、理解しにくい場合には、このステートメントの機能をマークする必要があります。 4. 絶対に必要であると思われる場合を除き、コメント内でモノグラムを作成しないでください。パターンを損なわずに美しく保ちながらアノテーションを変更するのは非常に難しいためです。 。 5. 一時的なコメントと永続的なコメントを区別するには、メソッドを使用してコメントに特殊な記号を配置できます。この利点は、見つけやすいことです。 6. ステートメントへの変更は、対応するコメントにマッピングされます。 7. コメントとコードの間には明確な隙間があり、どれがステートメントでどれがコメントであるかが一目でわかるようにする必要があります。コメントはコード行の前後に配置することも、コードの直後に少なくとも 2 つのスペースを空けることもできます。ただし、コードとコメントが同じ行にある場合は、コメントの後にコードを配置しないでください。コメントの後にコードを置かないでください。コメントはコードの途中に置かれます。