プログラミングルールDelcam International plc

読むのが楽しいトピックCodeの著者は、良いコードを書くためのルールを共有し、最終的に「他にどんなルールを使用していますか？」と尋ねました。 コードを読みやすくする方法は？」 私の指先には、数年前に働いていた1つの大きな英語オフィス（Delcam International plc）からのドキュメントがあります。このドキュメントは、CAD / CAMシステムを開発しており、世界中の数千人ではないにしても数百人のプログラマーを雇用しています。



当然のことながら、数千キロメートル離れた異なる言語を話し、特に異なる考え方を持つこのような多数のプログラマーの効果的な作業を編成するために、会社はプログラマーがコードを書くときに遵守しなければならない規則を採用しました。 従業員は、仕事に応募する際にこれらのルールを与えられます。従業員はルールをよく理解し、順守しなければなりません。 ルールは、基本的なコードのフォーマットや変数の命名など、多くの分野をカバーしています。



それらのいくつかは明白に見えるかもしれません、いくつかは非常に物議を醸す、いくつかは非常に有用です。 しかし、いずれにせよ、これは大企業の経験であり、導入されて以来、これには理由がありました。 自分に役立つことを学んだり、チームでそれらのいくつかを紹介したりすることで、チームとしてより効果的に仕事ができるようになります。

C ++でプログラミングするための一連のルールとガイド

Delcam International plcにて

---

1 はじめに

2 基本的なルールと推奨事項

3つの命名規則

4 コード形式とテキスト形式

5 コメント

6 制御オペレーター

7 ファイル

8 プリプロセッサ

9 クラス

10 変数

11 機能

12 コンストラクタ/デストラクタ/割り当て演算子

13 型キャスト

14 メモリの割り当てと削除

15のフレンドリーなクラスとフレンドリーな機能

16 ポータブルコードの記述

付録A：コードのフォーマットの例

---

1 はじめに

1. 1件





このドキュメントは、Delcam International plcのC ++プログラミングのルールとガイドのセットです。 会社としての私たちの目標は、維持しやすい正しいプログラムを作成することです（著者と他のプログラマーの両方が）。 したがって、この標準の目的は、すべてのDelcamコードを作成することです。

1. 保守が簡単：理解しやすい。 可能な限り明確でシンプルな; 一貫したスタイル。 信頼性：エラーなし; サポート中のエラーに対する耐性。 テストが簡単。
2. 結合：さまざまなプラットフォームおよびコンパイラーへの移植用に設計されています。 リサイクル可能。

執筆の大部分は日常の練習に推奨されているため、この文書は主にDelcamで働くプログラマーを対象としています。ホームツール、ソフトウェア、練習、習慣などへの頻繁に見られるリンクは受け入れられません。



1. 2つのソースと目標



この標準の準備では、いくつかの書籍とドキュメントが使用されました。





エレムテル

Mats HenricsonおよびEric Nyquist、 プログラミング

C ++、ルールと推奨事項 、（Ellemtel Telecommunication System

研究所）



腕

マーガレット・エリスとビャルン・ストラウストルプ、

注釈付きC ++リファレンスマニュアル（Addison Wesley）





方針

Ed Lambourne、 Delcamソフトウェア開発ポリシー 、

（内部メモ：Delcam International Plc。）



cppstd

デイビッド・ダニングトン他、 cppstd不満ファイル 、

（内部文書：Delcam International Plc。）





哲学

Paul Davies、David Dunnington、 データモデルプログラミング

哲学 、（内部文書：Delcam International Plc。）



マグワイア

スティーブマグワイア、 ソリッドコードの作成





ワリン

Steve Oualline、 C Elements of Style 、（M＆T

出版）



ホッブズ



Steve Hobbs、 Delcam Draft Cプログラミング標準 、

（Delcam International Plc。）



Ellemtel は優れた情報源です。ほぼすべての規則と推奨事項がこのドキュメントと交差しています。 貴重な情報源はcppstdの不満ファイルでもあり、豊富な情報を提供しました。 cppstdに携わったすべての人、特にPaul Davies に最も貢献して くれた人に感謝します 。

この標準にはトレーニング情報がほとんどありません。 基本的な構成、構文、およびC ++の使用に精通していることを前提としています。 ソフトウェアの設計と開発の問題も、このドキュメントの範囲外です。 言語の初心者は、同様の情報について本を参照することをお勧めします。 始めるには、 Keith WeiskampとBryan Flamig（Academic Press）による The Complete C ++ Primerを 試してください 。 ソフトウェア開発に関する優れた本は 、Bertrand MeyerによるObject Oriented Software Constructionです。





1. 3ルールと推奨事項



標準への違反には、ルール違反と推奨事項違反の2種類があります。 ルールの特徴：



定義：

従うべき指示。 文字通りの意味で、ルールは今後の目標の1つになります（はじめに説明します）。





例外：

このドキュメントで説明されている例外のみが許可されます。 各ルールは、考えられるすべての例外を文書化します。 新しい例外と変更が議論される場合があり、その結果、このドキュメントに反映されます。



強制：

コードを受け入れる委員会は、ルールに違反する場合、コードを拒否する必要があります。





管理：

コードは、自動テストおよび/またはチェックを受ける場合があります。



推奨事項の特徴：



定義：

正当な理由がない場合に従うべきアドバイス。 推奨事項に同意しないことは正当な理由ではありません。 推奨事項は、将来的には規則に入る傾向があるという事実から策定されます。





例外：

重要な例外は、個々の推奨事項とともに文書化されることがよくあります。 理由が正しいかどうかわからない場合は、標準の管理者とこの問題について話し合ってください。



強制：

推奨事項の違反を支持する準備をしてください。





管理：

コードは、自動テストおよび/またはチェックを受ける場合があります。





ルールや推奨事項が間違っていると思われる場合は、それらを無視するよりも変更することをお勧めします。 この声明には、ポリシーが強調されています。 7。

古いコードを再フォーマットまたは書き換える必要はありません。 サポート中にコードを変更する必要がある場合は、標準と一致する変更を行うことをお勧めします（ただし義務ではありません）。 展開時に古いコードで使用されていた書式設定方法を保存できますが、変更を行うときは、書式設定に関係のない規則と推奨事項に従ってください。





1. 4組織



  この文書の著者は人々であり（別の言い方をするにもかかわらず）、理想的ではありません。 このドキュメントは開発される予定であり、今後改善される予定です。

標準の進化を促進するために、ドキュメントバージョンコントロールは、アイテム名cppstd（C-Plus-Plus-STandarD）を使用してグリープシステムによって実装されます。 cppstdの詳細については、「gripe -doc」と入力して「gripe」と「gripe cppstd -help」と入力してください。 コメント、質問、提案などは不満を通して記録されるべきです。

ルールと推奨事項は、古くなった数字を処理しないように、数字ではなくキーワードによって与えられます。

• 前のキーワード
  
  r- がルールです。
• 前のキーワード
  
  s-- 推奨。

各ルールと推奨事項には、「簡潔なフォーム」と追加テキストのブロックがあります。 追加のテキストには、「簡潔なフォーム」と同じくらい重要であり、無視してはならない追加の条項、免責事項、および/または例外が含まれる場合があります。

---

2 基本的なルールと推奨事項



2. 1ポリシーガイド





r-gen-golden：ゴールデンルールに従います。

ルールに違反するたびに、これを明確に文書化する必要があります。 違反は、標準をサポートする人々によって承認される必要があり、その結果、変更されます。





s-gen-dupl：コードを複製しないでください。

コードの重複は致命的な罪と見なされます。 2つの関数に共通の個別のコード

機能。 可能な限り既存のクラスライブラリを使用します。 特に、2つの標準クラスライブラリが重要です。

Delcam：utils.dev。これには、C ++標準では使用できないソフトウェア（たとえば、抽象文字列クラス）と、 オブジェクトを格納するための基本的な抽象データ型を 含む e r.devが含まれます。



s-gen-reuse：再利用可能なコードを開発します。

可能な限り、ソフトウェアは、明確に定義され、明確に記述されたインターフェイスを備えた関連ツールライブラリのコンテキストで開発する必要があります。 ライブラリは、明確で文書化された階層的な方法でリンクする必要があります。





s-gen-simple：コードをシンプルにします。

「平均的な」プログラマー向けのコードを作成します。 スマートコードは理解しにくいため、少ない

再利用可能で保守が難しい。 常にシンプルさと読みやすさを重視します。 文献では、これはキス（「シンプルに保つ、愚かな」）原則として知られています。



s-gen-test：テストコードを記述してテストします。

チェックの強固なサブシステムを作成し、後で使用します。 小さなコードを書いてテストします。 デバッガをより頻繁に使用して、コードをステップごとに調べてください。エラーが発生するまで待たないでください。 エラーが見つかったらすぐに修正し、症状ではなく原因を除去します。







2. 2基本的なライティングガイド

プログラムの





s-gen-mc：プラットフォーム依存のコードを1か所に配置します。

プラットフォーム固有のコードを特別なファイルに配置します。 Delcamでは、これはapsl.dev/apsl/machine.hです。





s-gen-comp：コンパイラのエラーのためにコードを変更する必要がある場合、コメント

これを指摘するコードは、コンパイラに関する詳細を提供します。

「gripe cppbug」を使用してエラーをコンパイラに報告し、修正するための手順を実行できるようにします。



s-gen-opt：必要な場合にのみコードを最適化します。

パフォーマンスの問題があることがわかっている場合にのみ、コードを最適化します。 プログラムが遅すぎる場合は、最適化を開始する前にgroff ++または同等のツールを使用して問題の正確な原因を特定します。





s-gen-warn：すべてのコンパイラ警告を許可します。

可能であれば、コンパイラの警告をアクティブにして、エラーをローカライズし、コンパイラの新しいバージョンごとに書き換える必要のあるコードの部分を減らします（今日の警告は明日エラーになることが多いため）。

例：Cfrontベースのコンパイラを使用して、+ wフラグを使用してコンパイルし、可能な限り削除します

警告。



s-gen-asser t：アサーションを使用してコードをテストします。

アサーションについては、Maguireで説明されています。 Delcamでのアサーションの実装は、utils.dev / utils / ut_assert.hにあり、d0170400で説明されています。







バグの発見とテスト手順に関する追加のヘルプは、Maguireにあります。

---

3つの 命名規則





意味のある名前を選択することは、読みやすいコードを書く上で重要な部分です。 命名規則を一貫して使用すると、コードの可読性が向上し、人がプログラムの構造をすばやく理解できるようになります。 別の要件は、名前の競合のリスクを最小限に抑えるための順序を確立することです。 このセクションでは、読みやすさ、一貫性を促進し、大規模開発をサポートするために設計された命名規則について説明します。 以下のドキュメントでは、タイプはクラス、列挙型、またはタイプ定義です。



3. 1ライブラリプレフィックス



すべてのファイルとその内容（クラス、関数など）は特定のライブラリに属します。







r-nam-libpx：各ライブラリにプレフィックスを割り当てます。

各ライブラリは、このライブラリの一意の2文字または3文字のプレフィックスに関連付ける必要があります。 プレフィックス文字は小文字でなければなりません。



r-nam-glob：すべてのグローバル名にライブラリプレフィックスを使用します。

ライブラリ内のオブジェクトがグローバルネームスペースの一部である場合、その名前はライブラリプレフィックスで始まる必要があります。







名前をプレフィックスで構成する方法に関する規則は、次のセクションで説明します。 著者またはサポート担当者の責任は、ライブラリ内で名前の競合がないことを確認することです。 プレフィックスは、ライブラリの外部での名前の競合を（できれば！）防ぎます。



3. 2型、変数、関数、マクロの名前



次のルールは、さまざまなオブジェクトに名前を付ける方法を説明しています。 例は、ライブラリプレフィックスがz z であるという仮定の下で与えられています 。







r-nam-type：タイプ名は大文字で始まります。

型名は小さな文字で書かれ、新しい単語はそれぞれ大文字で始まります。 アンダースコアを含めることはできません。 名前の前には、小文字の接頭辞を付ける必要があります。 ネストされたクラス/列挙型（enum）はまれであり、SGIおよびHPコンパイラで問題が発生する可能性があるため、それらの使用は推奨されません。 ただし、それらを使用する場合は、コンパイラの問題のためにグローバルクラス名については、それらの名前を選択する必要があります。

例：class zzMyClass {

...





r-nam-var：変数、ローカル定数、および関数引数の命名については、規定の方法に従ってください。

変数、ローカル定数、および関数の引数の名前は、単語を1つのアンダースコアで区切った小さな文字で記述されます。 プレフィックスは次のようになります。









例：const int local_const; 例：

int local_var; 例：int zz_global_var; 例：int m_member_var; 例：

static int s_static_member_var; //（推奨）

例：void f（int a_argument）;

//（推奨）





r-nam-glcon：グローバル定数と列挙定数（enum）の名前は大文字で書かれています。

単語を区切るには、アンダースコアを1つ使用します。 プレフィックスは小文字でなければなりません。 例：

const int zzGLOBAL_CONST;

例：enum zzKind {zzONE_KIND、

..



r-nam-func：関数名は小文字で書かれています。

単語を区切るには、アンダースコアを1つ使用します。 グローバル関数の前には小文字の接頭辞が付き、その後にアンダースコアが続きます。 クラスメンバ関数はプレフィックスを必要としません。 例外：r-nam-farg。



例外：r-nam-fclass。



r-nam-farg：プレフィックスを含む型引数がグローバル関数に渡される場合、関数名にプレフィックスを追加する必要はありません。

この場合の名前の競合のリスクは非常に小さいです。 これにより、プログラマーは、名前を接頭辞で構文的に混乱させることなく、クラスに密接に関連する関数を作成できます。 たとえば、クラス 'int zzClass :: f（）const'およびフレンドリ関数 'int f（const zzClass＆）'のメンバー関数を宣言すると、インスタンスが式の評価に関与する場合に構文を簡素化できます。

「i =（a + b）.f（）」は「i = f（a + b）」に置き換えられます。 例：void zzClass :: member（）; 例：

void zz_global_func（）;

例：void global_func（const

zzClass＆）;





r-nam-fclass：型名が関数名の一部である場合、型名は型定義のとおりに記述する必要があります（大文字を含む）。

型が関数と同じライブラリで宣言されている場合、関数名に追加のライブラリプレフィックスを追加する必要はありません。 それはすでにクラス名に含まれており、r-nam-fargのように、他のライブラリと名前が競合するリスクは非常に小さいです。 例：void test_zzClass（）; 例：void zzClass :: member（）;

例：void zz_global_func（）;

例：void global_func（const

zzClass＆）;



s-nam-funcstd：使用

クラスメンバ関数の標準名（存在する場合）。

いくつかのクラスメンバー関数

多くのクラスに共通しており、それらの名前は標準化されています：を参照

セクション12.2.1。 アクセス関数がタイプ<zzAttrib>のクラス<attrib>の属性を設定する場合

プロトタイプvoid set_ <attrib>（const <zzAttrib>＆）が必要です;。

アクセス関数が属性を返す場合、プロトタイプが必要です

const <zzAttrib>＆<attrib>（）constまたは<zzAttrib> <attrib>（）

属性に代入演算子とコピーコンストラクターがある場合はconst

（セクション12.3を参照）。



r-nam-macro：マクロ名は大文字です。

単語を区切るには、アンダースコアを1つ使用します。 ライブラリプレフィックスは大文字で入力し、その後にアンダースコアを入力する必要があります。 r-def-minusd§8も参照してください。 例外：ヘッダーファイルのインクルードの防止に関係するマクロ定義は、r-cpp-ifdef§8.2のように記述する必要があります。



例外：メインクラスに関連付けられた「宣言」および「実装」のマクロ定義は、任意に呼び出すことができます。

例：#define ZZ_LIB_MACRO

0



r-nam-und：開始しない

アンダースコア付きの名前。

命名規則では、アンダースコアで始まるタイプまたは変数名は除外されます。 識別子での2つのアンダースコアの使用は、コンパイラによる内部使用のためにANSI-C標準に従って予約されています。

単一のアンダースコアで始まる名前は、標準ライブラリ関数でよく使用されます（例：「_main」および「_exit」）。





r-nam-twound：2つのアンダースコアを連続して使用しないでください。





付録Bは、すべての命名規則の一般的な表を提供します。



3. 2つのスタイルの推奨事項







s-nam-abbrev：略語の使用頻度を減らします。

略語が広く知られている場合にのみ（会社内または世界で）単語を省略します。

たとえば、「DDX」は、Delcamで理解される略語です。 ループ変数「i」は「標準」プログラマのショートカットであり、「array_index」よりもはるかに優れています。 読みにくい名前は悪いと見なされます。



s-nam-length：名前の長さを無理にしないでください。



一部の環境では、認識される文字の数に制限があるため、名前を長くしすぎないでください。 たとえば、unix 'ar'コマンドは、15文字より長いファイル名を切り捨てます。



s-nam-desc：単純でわかりやすい名前を使用します。

変数の名前は、その使用について説明する必要があります。 変数名に1つ、2つの単語が含まれている場合が最適です。 3の場合、これはすでに注意を引き、4の場合、名前は読みにくい場合があります。 2単語の名前を作成するときは、最も重要な単語を最初に置きます。



s-nam-dif：名前は大幅に異なる必要があります。

1、2文字だけ異なる変数名を使用しないでください。 文字の場合にのみ異なるタイプ名を使用しないでください。 同時に、同様の機能を実行する変数には同様の名前を使用します。





s-nam-std：標準ライブラリで使用される名前の使用を避けます。

マクロ定義はルールによって制限されないため、これはローカルオブジェクトにも推奨されます（標準ライブラリ内のオブジェクトにプレフィックスがある場合、問題は軽減されます）。 標準ライブラリでは非常に一般的な（したがって広く使用されている）単語（たとえば、「インデックス」）が使用されることがあるため、これはルールではなく推奨事項です。





3.4ファイル名





ファイルには4つのタイプがあります。

1. ヘッダーファイルには型定義、関数プロトタイプなどが含まれます。ソースファイルにはクラス実装などが含まれます。インラインファイルにはインライン関数が含まれます。
2. アウトラインファイルにより、インライン関数の非インラインバージョンがデバッグ目的で使用できるようになります。

ファイルの命名規則を以下に示します。





r-nam-clfile：クラス実装を含むファイルには、クラスと同じ名前が必要です。

ファイル名は、クラス名と同じ大文字と小文字で記述する必要があります。 これは、メインクラスにも適用されます。 このルールは、ヘッダー、インライン、およびソースファイルに適用されます。





r-nam-utfile：一連のユーティリティを実装するファイルには、ライブラリプレフィックスが前に付いた小文字の名前が必要です。

プレフィックスは、アンダースコア1つで名前と区切る必要があります。 このルールは、ヘッダー、インライン、およびソースファイルに適用されます。



r-nam-enum：列挙型を1つだけ含むヘッダーファイルには、列挙型と同じ名前を付けることができます。



r-nam-ext：ファイル拡張子：ヘッダー.h、ソーステキスト/アウトライン.c、インライン.i。



Ellemtelは、CコンパイラとC ++コンパイラの両方で受け入れ可能なファイルに対して、「。hh」、「。cc」、「。icc」を予約し、「。h」と「.c」を予約します。 すべてのDelcamコードは、ルールに従ってC ++をコンパイルする必要があるため、このような区別は行いません。



r-nam-outline：アウトラインファイルには、対応するヘッダーと同じ名前が付けられ、「ファイル拡張子」の前に「I」が追加されます。



r-nam-split：ソーステキストファイルが大きくなり、分割する必要がある場合、新しい各ファイルの名前は、古いファイルの名前にアンダースコアと小文字の単語が続いたものになります。

たとえば、zzClass.cファイルに、別のファイルに実装されているメンバー関数zzClass :: member（）が含まれている場合、そのファイルはzzClass_member.cと呼ばれる場合があります。





例：zzClass.c：zzClassクラスを実装するソースファイル。 zz_utils.h：ユーティリティヘッダーファイル。 zz_utils.i：zz_utils.hで定義されているインライン関数の実装。

zzClassI.c：zzClass.hで定義されているインライン関数のアウトラインバージョン。

---

4 コード形式とテキスト形式



このセクションでは、コードの外観を定義します。

4. 1一般的なコード形式







r-fmt-brace：有効なブラケットスタイルのみを使用します。

ブラケットは、K＆Rの「短い」形式に従って配置する必要があります。開始ブラケットは、前のコードの直後の行末にあります。 閉じかっこは、開きかっこが配置されている行の最初の非空白文字に対応する列の別の行にあります。 2つの角括弧の間のコードはインデントされています。

例：





if（function_returns_true（））{

execute_this_code（）;

}







例外：関数の開始ブラケット（{）は別の行になければなりません。

例外：関数の引数は別の行を占める場合があります。



r-fmt-lines：文字列は79文字を超えてはなりません。

この制限は、私たちが使用している標準の「emacs」設定が長い行が折りたたまれているウィンドウを作成するという事実のために選択されました。 さらに、80x24（80x25）は古い端末からの一般的なウィンドウサイズであり、最小化された行は読みにくくなります。



r-fmt-indent：インデントは2つのスペースです。



ロジックの新しいレベルごとに1レベル戻ります。

例外：要素が整列している場合、if-elseシーケンスは読みやすくなります-r-if-elseifを参照してください。



r-fmt-tabs：タブ文字を使用しないでください。

コードのサポート中にインデントを維持するのが難しくなります。 他のエキゾチックなキャラクターの使用は避けてください。



s-fmt-sep：不要なセパレータを使用しないでください。



例：列挙の最後の値の後に余分なコンマを使用しないでください（「strict」コンパイラーは、IBMなどのエラーをスローします）。





4. 2オペレーター







s-fmt-long：非常に長いステートメントの使用を避けます。

代わりに、いくつかの短いステートメントを使用してください。



s-fmt-stat：各ステートメントを別々の行に配置します。

これを行わない場合、プログラムの明瞭さが改善されることを確認する必要があります。



s-fmt-col：同じ行に複数のステートメントがある場合は、ステートメントを列にグループ化します。





s-fmt-split：改行するときは、もう1レベル戻ります。

1行を複数の行に分割する必要がある場合は、最初の行を除くすべての行を1レベル追加します。 例外：s-fmt-splitexprを参照してください。

例外：管理構造は、対応するセクション（§6）で説明されているように分割されます。





4. 3つの式







s-fmt-splitexpr：式を分割するとき、同じ論理レベルの部分式は垂直に整列する必要があります。

ネストレベルが高い場所で式を壊さないでください。 算術演算子と論理演算子は、次の行の先頭ではなく、行の末尾に配置してください。 これにより、長い式のロジックを簡単にトレースできます。

例：





結果=（（（x1 + 1）*（x1 + 1））-

（（y1 + 1）*（y1 + 1）））;





例：割り当て式は次のように分解できます。







結果= a_long *斜辺+

2.0 * cos（アルファ）;





壊れた式を整列させる場合、サブ式のいずれかまたは両方を括弧で囲む必要があります。

例：





if（（a && b）||

c）{//これをしない



次のように書く方が良いです。







if（（a && b）||

©）{//はるかに良い







s-fmt-prec：操作を明確にするために、より頻繁に括弧を使用します。

覚えていない限り、テーブルの優先順位を探しないでください。代わりに括弧を使用してください。 操作の優先順位を思い出せない場合、コードを読み取った人もそれを覚えていない可能性が高くなります。 原則として、操作+、/と+、-の間の優先順位。 他のすべての場合には括弧を使用します。





4. 4つのスペース





これらのガイドラインは、インデントに使用されるスペースではなく、行内のスペースに適用されます。

1. 複数のスペースを使用しないでください。
   
   （たとえば、 'class <class>'で検索すると、クラス<clas s>の定義が見つかります ）。
2. ポインター変数と「[」の間にスペースを使用しないでください（たとえば、「array [」で検索すると、配列の要素への参照が見つかるはずです）。 関数名と '（'の間にスペースを使用しないでください（たとえば、 'func（'で検索すると、すべての関数呼び出しが見つかります）。常に '（'と制御ステートメントの間にスペースを入力します（たとえば、 'while（x）'を使用し、 「while（x）」ではありません）常に「{」と「}」の前にスペースを入力します（行の先頭にある場合を除く）。
3. 常に「{」と「}」の後にスペースを入力します（行末にある場合を除く）。
4. 文字 '、;）]'の前にスペースを入れ ないでください 。
5. '（'または ']'の後にスペースを入力しないでください。定義と式のコンマの後にスペースを配置することをお勧めしますが、関数呼び出しの引数の間にスペースを配置することは推奨されません。単項演算とオペランドの間にスペースを入力します。「::」、「。」、「->」の前後にスペースを使用しないでくださいキーワード「演算子」の後にスペースを入力しないでください。
6. 上記の推奨事項を除き、演算子の前後のスペースはオプションです。

s-fmt-space：スペースの使用に関するガイドラインに従ってください。

---

5 コメント





このセクションでは、コメントの書き方について説明します。 このドキュメントの別の部分では、コメントを書く場所について説明します。