C++の命名規則とは、変数名、関数名、クラス名、構造体名、定数名、ファイル名などに対して、どのような名前を付けるかを決めるルールのことです。
C++には、言語全体で完全に統一された公式の命名規則があるわけではありません。
そのため、プロジェクトや会社、使用しているライブラリ、フレームワークによって命名スタイルは異なります。
ただし、C++には識別子として使える名前や、使うべきではない予約名に関する言語仕様上のルールがあります。
また、実務で読みやすく保守しやすいコードを書くための慣習もあります。
そのため、C++の命名では「言語仕様として守るべきルール」と「プロジェクト内で統一すべきスタイル」の両方を意識することが大切です。
C++の命名規則で重要な考え方
読み手に意味が伝わる名前にする
C++の命名で最も重要なのは、名前を見ただけで役割や意味が分かるようにすることです。
たとえば、短すぎる名前や抽象的すぎる名前は、後からコードを読んだときに意味を理解しにくくなります。
一時的なループ変数であれば短い名前でも問題ありませんが、業務ロジックや重要な値には、具体的で分かりやすい名前を付けるべきです。
変数名であれば「何の値なのか」、関数名であれば「何をする処理なのか」、クラス名であれば「何を表す型なのか」が分かるようにします。
プロジェクト内で一貫性を持たせる
C++では、キャメルケース、パスカルケース、スネークケースなど、複数の命名スタイルが使われます。
どのスタイルを選ぶかも大切ですが、それ以上に重要なのは、プロジェクト内で一貫していることです。
同じプロジェクト内で、ある関数はキャメルケース、別の関数はスネークケース、さらに別の関数はパスカルケースという状態になると、コード全体の統一感がなくなり、可読性が下がります。
既存プロジェクトに参加する場合は、自分の好みよりも既存コードの命名規則に合わせることが基本です。
新規プロジェクトの場合は、最初に命名ルールを決めておくと、後からコードが増えても管理しやすくなります。
型よりも役割を名前に含める
昔のC/C++では、変数名に型を表す接頭辞を付ける書き方が使われることがありました。
しかし、現代のC++では、型そのものよりも、その値が何を意味するのかを名前に含めるほうが一般的です。
型情報はIDEやエディタ、コンパイラで確認しやすいため、名前に型を含めすぎると、かえって保守しづらくなる場合があります。
たとえば、最初は整数だった値が後から別の数値型に変わった場合、型を表す接頭辞が名前に残っていると、実態と名前が一致しなくなることがあります。
そのため、C++の命名では「これは整数かどうか」よりも、「これはユーザー数なのか」「商品数なのか」「合計金額なのか」といった意味を表す名前にすることが大切です。
C++でよく使われる命名スタイル
キャメルケース
キャメルケースは、複数の単語をつなげるときに、2語目以降の先頭を大文字にする書き方です。
先頭を小文字にする形式は、特にローワーキャメルケースと呼ばれます。
C++では、変数名や関数名に使われることがあります。
たとえば、ユーザー名、合計金額、設定を読み込む処理などを表す名前で使われます。
キャメルケースは、単語の区切りが分かりやすく、比較的短く書ける点が特徴です。
パスカルケース
パスカルケースは、すべての単語の先頭を大文字にする書き方です。
C++では、クラス名、構造体名、列挙型名など、型を表す名前に使われることが多いです。
クラスや構造体は、プログラム上の「もの」や「概念」を表すため、パスカルケースにすると変数名や関数名と区別しやすくなります。
スネークケース
スネークケースは、単語をアンダースコアで区切る書き方です。
C++標準ライブラリでは、小文字やスネークケースに近い名前が多く使われています。
たとえば、標準ライブラリの関数名や型名には、小文字やアンダースコアを使った名前が多く見られます。
ただし、一般のアプリケーションコードで、すべてを標準ライブラリ風にする必要はありません。
クラス名はパスカルケース、関数名や変数名はキャメルケースまたはスネークケースにするなど、プロジェクトごとの方針に合わせることが大切です。
アッパースネークケース
アッパースネークケースは、すべて大文字にして、単語をアンダースコアで区切る書き方です。
C++では、主にマクロ名に使われることが多いです。
また、古いコードや一部のプロジェクトでは、定数名にも使われることがあります。
ただし、現代的なC++では、マクロと定数を区別しやすくするために、定数にはアッパースネークケースを使わない方針のプロジェクトもあります。
マクロは名前の衝突や予期しない置換が起こりやすいため、必要がない場合は、定数にはマクロではなく、より安全なC++の定数機能を使うのが一般的です。
変数名の命名規則
変数名は意味が分かる名前にする
変数名は、その値が何を表しているのか分かるように付けます。
短すぎる名前や、意味が広すぎる名前は避けたほうがよいです。
たとえば、単に「データ」「値」「一時的なもの」といった意味の名前は、コードが大きくなるほど役割が分かりにくくなります。
ユーザーの年齢であればユーザーの年齢だと分かる名前、商品の個数であれば商品の個数だと分かる名前、合計金額であれば合計金額だと分かる名前にするのが理想です。
短い名前を使ってもよい場面
すべての変数名を長くすればよいわけではありません。
ループのカウンタや座標、数学的に意味が明確な値などでは、短い名前が適している場合もあります。
ただし、業務上の意味を持つ値や、複数行にわたって使われる値には、できるだけ具体的な名前を付けたほうが読みやすくなります。
bool型の変数名
bool型の変数は、条件文として読んだときに自然になる名前にすると分かりやすくなります。
よく使われる接頭辞には、次のようなものがあります。
- 「is」は状態を表すときに使われます。
- 「has」は何かを持っているかどうかを表すときに使われます。
- 「can」は何かが可能かどうかを表すときに使われます。
- 「should」は何かをすべきかどうかを表すときに使われます。
bool変数では、否定形の名前を使うと読みにくくなる場合があります。
特に、条件式の中で否定を重ねると意味が分かりにくくなります。
そのため、できるだけ肯定形の名前にして、必要な場面で否定して使うほうが読みやすくなります。
個数や長さを表す変数名
個数を表す場合は「count」、サイズを表す場合は「size」、文字列や配列などの長さを表す場合は「length」がよく使われます。
これらは似ていますが、意味が少し異なります。
- 「count」は要素や件数の数を表すときに使います。
- 「size」はサイズ、容量、または要素数を表すときに使います。
- 「length」は文字列や距離、長さを表すときに使います。
意味に応じて使い分けると、名前だけで値の性質が伝わりやすくなります。
関数名の命名規則
関数名は処理内容が分かる名前にする
関数名は、その関数が何をするのか分かる名前にします。
関数は処理や動作を表すことが多いため、動詞から始める名前がよく使われます。
たとえば、計算する、作成する、削除する、読み込む、保存する、更新する、といった意味を名前に含めます。
関数名を見ただけで処理内容が分かると、コードの流れを理解しやすくなります。
値を取得する関数
値を取得する関数には、「get」を付けることがあります。
ただし、C++では必ずしもすべての取得関数に「get」を付ける必要はありません。
標準ライブラリでも、サイズを返す関数や空かどうかを返す関数などは、短く自然な名前になっています。
単純に値を返すだけの関数であれば、名詞に近い名前にすることもあります。
一方で、取得処理にコストがかかる場合や、外部から何かを読み込む場合は、処理内容が分かる名前にしたほうが親切です。
boolを返す関数
boolを返す関数は、条件文として自然に読める名前にします。
状態を確認する関数であれば「is」、何かを持っているか確認する関数であれば「has」、実行可能か確認する関数であれば「can」、実行すべきか判断する関数であれば「should」などを使うと分かりやすくなります。
条件文の中で読んだときに、英語として自然に意味が通る名前を意識するとよいです。
クラス名の命名規則
クラス名は名詞または名詞句にする
クラス名は、基本的に名詞または名詞句にします。
クラスは、プログラム上の概念、データ、役割、機能のまとまりを表すため、動詞よりも名詞のほうが自然です。
たとえば、ユーザーを表すクラス、注文を表すクラス、ファイルを読み込む役割を持つクラス、支払い処理を担当するクラスなど、それぞれの役割が分かる名前にします。
処理そのものを表すような動詞の名前にすると、関数名のように見えてしまうため注意が必要です。
クラス名にはパスカルケースがよく使われる
C++では、クラス名にパスカルケースを使うスタイルが広く見られます。
型名をパスカルケースにすると、変数名や関数名と区別しやすくなります。
ただし、C++標準ライブラリのように小文字を使うスタイルも存在します。
そのため、どちらが絶対に正しいというより、プロジェクト内で統一されているかが重要です。
構造体名の命名規則
構造体名も型名として扱う
C++では、構造体も型の一種です。
そのため、構造体名もクラス名と同じように、パスカルケースで書かれることが多いです。
構造体は、主にデータをまとめるために使われることが多く、クラスは不変条件や振る舞いを持つ型として使われることが多いです。
ただし、C++における構造体とクラスの主な言語仕様上の違いは、デフォルトのアクセス指定です。
構造体はデフォルトでpublic、クラスはデフォルトでprivateになります。
命名規則としては、どちらも型名であるため、同じスタイルで統一すると分かりやすくなります。
メンバ変数の命名規則
メンバ変数はローカル変数と区別できるようにする
C++では、クラスのメンバ変数をローカル変数や関数の引数と区別するために、特別な命名ルールを設けることがあります。
代表的なのは、メンバ変数の末尾にアンダースコアを付けるスタイルです。
この方法はC++でよく使われており、コンストラクタの引数名とメンバ変数名を区別しやすいという利点があります。
また、メンバ変数の先頭に「m_」を付けるスタイルもあります。
これは古くからあるC++コードや、特定の開発現場で見られる命名方法です。
一方で、接頭辞や接尾辞を付けずに、必要な場面で明示的にメンバ変数であることを示すスタイルもあります。
どの方法でも間違いではありませんが、プロジェクト内で統一することが大切です。
先頭アンダースコアは避ける
メンバ変数を区別したいからといって、先頭にアンダースコアを付ける命名は避けたほうが安全です。
C++では、アンダースコアで始まる名前や、ダブルアンダースコアを含む名前には予約名に関するルールがあります。
特に、アンダースコア＋大文字で始まる名前や、ダブルアンダースコアを含む名前は使うべきではありません。
実務上は、ユーザー定義の名前では先頭アンダースコアを避け、メンバ変数を区別したい場合は末尾アンダースコアを使うほうが安全です。
定数名の命名規則
定数名はプロジェクト差が大きい
C++の定数名は、プロジェクトによって命名スタイルが分かれやすい部分です。
定数には、パスカルケース、スネークケース、k接頭辞付きの名前、アッパースネークケースなど、さまざまなスタイルが使われます。
Google C++ Style Guideのように、定数に「k」を付けるスタイルもあります。
この方法では、通常の変数と定数を見分けやすくなります。
一方で、標準ライブラリ風に小文字のスネークケースを使うプロジェクトもあります。
マクロと定数は区別する
アッパースネークケースは、主にマクロ名でよく使われます。
そのため、定数にもアッパースネークケースを使うと、マクロとの区別がつきにくくなる場合があります。
現代的なC++では、マクロではなく、より安全な定数機能を使うことが多いため、定数名はマクロと区別しやすいスタイルにするのがおすすめです。
ただし、既存プロジェクトで定数にアッパースネークケースを使っている場合は、そのルールに合わせるのが基本です。
マクロ名の命名規則
マクロ名はアッパースネークケースが一般的
C++のマクロ名は、アッパースネークケースで書かれることが一般的です。
マクロはプリプロセッサによって置換されるため、通常の変数や関数とは性質が異なります。
そのため、見た目でマクロだと分かるように、大文字で目立たせるスタイルが使われます。
マクロは必要最小限にする
C++では、マクロは名前空間の影響を受けず、意図しない名前衝突を起こす可能性があります。
また、型チェックが効きにくく、デバッグしづらい場合もあります。
そのため、定数や簡単な処理を表すためだけにマクロを使うのは、現代的なC++ではあまり推奨されません。
必要がない場合は、C++の定数機能や関数、テンプレートなどを使うほうが安全です。
どうしてもマクロを使う場合は、プロジェクト名やモジュール名を含めるなどして、名前衝突を避ける工夫をするとよいです。
enumの命名規則
enum名は型名として扱う
列挙型も型の一種なので、enum名にはクラス名や構造体名と同じように、パスカルケースを使うことが多いです。
列挙型は状態や種類を表すため、注文状態、ユーザー種別、エラー種別など、何を分類しているのか分かる名前にします。
enum classを使うと名前衝突を避けやすい
現代的なC++では、従来のenumよりもenum classを使うことが推奨される場面が多いです。
enum classを使うと、列挙子が列挙型のスコープ内に閉じ込められるため、名前衝突を避けやすくなります。
従来のenumでは、列挙子が外側のスコープに出てしまうため、他の名前と衝突する可能性があります。
その場合は接頭辞を付けて区別することもありますが、可能であればenum classを使うほうが安全です。
名前空間の命名規則
名前空間名は小文字がよく使われる
名前空間名には、小文字やスネークケースが使われることが多いです。
名前空間は、クラスや関数、変数などを分類し、名前の衝突を避けるために使います。
そのため、プロジェクト名や機能名を反映した名前にすると分かりやすくなります。
一般的すぎる名前には注意する
「util」や「common」のような名前は便利ですが、トップレベルの名前空間として使うには一般的すぎる場合があります。
一般的すぎる名前は、他のライブラリやコードと衝突したり、役割が曖昧になったりする可能性があります。
使う場合は、プロジェクト固有の名前空間の下に置くと安全です。
ファイル名の命名規則
ファイル名もプロジェクト内で統一する
C++のファイル名には、スネークケースやパスカルケースなど、複数のスタイルがあります。
クラス名に合わせてパスカルケースにするプロジェクトもあれば、すべて小文字のスネークケースにするプロジェクトもあります。
クロスプラットフォーム開発では、ファイル名の大文字・小文字の扱いに注意が必要です。
WindowsとLinuxでは、大文字・小文字の扱いが異なる場合があるため、小文字で統一したファイル名にするとトラブルを避けやすくなります。
拡張子にも複数の流儀がある
C++のソースファイルには、複数の拡張子が使われます。
ヘッダーファイルにも、いくつかの拡張子があります。
どれが絶対に正しいというより、プロジェクトで統一することが重要です。
Google C++ Style Guideでは、ソースファイルに特定の拡張子、ヘッダーファイルに特定の拡張子を使う方針があります。
一方で、一般的なC++プロジェクトでは別の拡張子も広く使われています。
新規プロジェクトでは、C言語と共用するヘッダーなのか、C++専用のヘッダーなのかを考慮して拡張子を決めるとよいです。
テンプレートの命名規則
単純なテンプレートでは短い名前も使われる
C++のテンプレート型引数では、短い名前がよく使われます。
特に、単純な型を1つだけ扱う場合は、慣習的に短い名前を使うことがあります。
ただし、テンプレートが複雑になる場合や、複数の型を扱う場合は、意味の分かる名前にしたほうが読みやすくなります。
複雑なテンプレートでは意味を明確にする
テンプレート型引数がキー、値、イテレータ、要素型など、特定の役割を持つ場合は、その役割が分かる名前にすると親切です。
短い名前は簡潔ですが、複雑なコードでは理解の妨げになることがあります。
テンプレートでは、簡潔さと分かりやすさのバランスを意識することが大切です。
ポインタや参照の命名規則
型情報を名前に含めすぎない
ポインタや参照であることを名前に含めるかどうかは、プロジェクトによって異なります。
現代的なC++では、型を見ればポインタか参照か分かるため、必ずしも名前に「ポインタ」や「参照」を示す語を含める必要はありません。
それよりも、その変数が何を表しているのか、所有権を持っているのか、借りているだけなのかといった意味を明確にするほうが重要です。
所有権を表す名前は有効な場合がある
C++では、所有権の扱いが重要です。
スマートポインタなどを使う場合、変数名に所有していることや借用していることが分かる語を含めると、意図が伝わりやすくなる場合があります。
ただし、すべてのポインタに機械的な接尾辞を付ける必要はありません。
あくまで、コードの意味を分かりやすくするために必要な場合に使うのがよいです。
グローバル変数の命名規則
可変のグローバル変数は避ける
C++では、可変のグローバル変数はできるだけ避けるべきです。
グローバル変数は、どこから変更されるのか分かりにくく、予期しない副作用の原因になることがあります。
また、テストや保守を難しくすることもあります。
どうしても使う場合は、グローバルであることが分かる命名にするプロジェクトもあります。
定数はグローバルに置かれることもある
一方で、変更されない定数を名前空間スコープに置くことは一般的に行われます。
可変のグローバル状態と、変更されない定数は分けて考える必要があります。
定数をグローバルに置く場合でも、適切な名前空間に入れて、名前衝突を避けることが大切です。
予約名に関する注意点
ダブルアンダースコアを含む名前は避ける
C++では、ダブルアンダースコアを含む名前は、処理系や標準ライブラリのために予約されています。
そのため、ユーザーが定義する変数名、関数名、クラス名などに、ダブルアンダースコアを含めるべきではありません。
アンダースコア＋大文字で始まる名前は避ける
アンダースコアに続いて大文字で始まる名前も予約されています。
このような名前は、一見すると内部実装用の名前のように見えるため、ユーザーコードでは使わないようにします。
先頭アンダースコアは基本的に避ける
グローバル名前空間では、アンダースコアから始まる名前も予約の対象になります。
ローカル変数やクラスメンバでは、厳密には常に禁止とは限らないケースもありますが、実務上は混乱を避けるため、ユーザー定義の名前では先頭アンダースコアを使わないほうが安全です。
メンバ変数を区別したい場合は、先頭ではなく末尾にアンダースコアを付けるスタイルがよく使われます。
Google C++ Style Guide風の命名規則
Google風の特徴
Google C++ Style Guideに寄せる場合、型名はパスカルケース、変数名はスネークケース、クラスのメンバ変数は末尾アンダースコア付き、定数はk接頭辞付きの名前にするのが特徴です。
また、通常の関数名はパスカルケースにする方針です。
このスタイルは、一般的なキャメルケース中心の命名とは少し異なります。
Google風と一般的なキャメルケースを混ぜない
注意したいのは、Google風の命名と、一般的なローワーキャメルケース中心の命名を混ぜないことです。
たとえば、変数名はスネークケース、関数名はローワーキャメルケース、定数名はk接頭辞、クラス名はパスカルケースというように、複数の方針を混ぜると、統一感が弱くなる場合があります。
Google風にするならGoogle風で統一し、キャメルケース寄りにするならキャメルケース寄りで統一するのが分かりやすいです。
Unreal Engine風の命名規則
Unreal Engineには独自の命名規則がある
Unreal Engineでは、通常のC++とは異なる独自の命名規則があります。
型や用途に応じて接頭辞を付ける文化があり、UObject派生クラス、AActor派生クラス、構造体、列挙型、インターフェース、テンプレートクラス、bool変数などで命名ルールが分かれています。
これは一般的なC++というより、Unreal Engineのフレームワークに合わせた命名規則です。
Unreal Engineでは公式ルールに従う
Unreal Engineのコードを書く場合は、一般的なC++の好みよりも、Unreal Engineの公式コーディング規約に従うことが重要です。
Unreal Engineでは、ツールやコード生成の仕組みが命名規則と関係している場合もあるため、独自判断で命名を崩すと、可読性だけでなく開発効率にも影響することがあります。
Qt風の命名規則
QtではlowerCamelCaseがよく使われる
Qtでは、変数名や関数名にローワーキャメルケースがよく使われます。
関数名は小文字で始まり、2語目以降の単語の先頭を大文字にする形式が基本です。
QtのAPIに合わせてコードを書く場合は、Qt風の命名に寄せると、全体の統一感が出やすくなります。
Qtのクラス名にはQ接頭辞が多い
Qt本体のpublic classでは、クラス名にQ接頭辞が使われることが多いです。
ただし、自作クラスまで必ずQで始めるべきとは限りません。
プロジェクトの方針や、Qt本体のクラスと区別したいかどうかを考慮して決めるとよいです。
ハンガリアン記法について
現代C++ではあまり推奨されない
ハンガリアン記法とは、変数名に型や意味を表す接頭辞を付ける命名方法です。
古いC/C++コードでは使われることがありましたが、現代的なC++では一般的にはあまり推奨されません。
理由は、型情報を名前に含めると、型を変更したときに名前と実態がずれる可能性があるためです。
また、現在はIDEやエディタで型を確認しやすいため、名前に型を含める必要性が以前より低くなっています。
フレームワーク固有のルールとは区別する
ただし、Unreal Engineのように、bool変数に特定の接頭辞を付ける公式ルールがあるフレームワークもあります。
このような場合は、古いハンガリアン記法として一律に避けるのではなく、そのフレームワークの規約として扱うべきです。
C++の命名で避けたい名前
短すぎる名前
短すぎる名前は、意味が伝わりにくくなります。
特に、業務上の意味を持つ値や、複数の処理で使われる値には、具体的な名前を付けるべきです。
ただし、ループカウンタや座標のように、文脈上意味が明確な場合は、短い名前でも問題ありません。
意味が広すぎる名前
「data」「value」「temp」「info」などの名前は便利ですが、意味が広すぎるため注意が必要です。
小さなスコープ内で一時的に使う場合は問題ありませんが、重要な変数やメンバ変数に使うと、何を表しているのか分かりにくくなります。
より具体的に、ユーザー名、商品数、合計金額、税率、設定情報など、役割が伝わる名前にするのが理想です。
略しすぎた名前
略語を使いすぎると、読み手によって解釈が変わることがあります。
一般的に広く使われている略語であれば問題ありませんが、独自の略語や分かりにくい省略は避けたほうが安全です。
特にチーム開発では、自分だけが分かる略語ではなく、他の人が読んでも意味を理解できる名前にすることが大切です。
否定形のbool名
bool変数やbool関数では、否定形の名前に注意が必要です。
否定形の名前は、さらに条件式で否定されたときに意味が分かりにくくなります。
できるだけ肯定形の名前を使い、必要な場面で否定するほうが読みやすくなります。
実務でおすすめの命名ルール
新規プロジェクトでは最初にルールを決める
新規プロジェクトでC++を書く場合は、最初に命名ルールを決めておくと後から管理しやすくなります。
たとえば、型名はパスカルケース、関数名と変数名はローワーキャメルケース、メンバ変数は末尾アンダースコア、定数はk接頭辞付きにする、といったルールです。
または、Google風に、型名はパスカルケース、関数名もパスカルケース、変数名はスネークケース、メンバ変数は末尾アンダースコア、定数はk接頭辞付きにする方法もあります。
どちらが絶対に正しいというわけではありません。重要なのは、混在させずに一貫させることです。
既存プロジェクトでは既存ルールを優先する
既存プロジェクトに参加する場合は、自分が好む命名規則よりも、そのプロジェクトで使われている命名規則を優先します。
命名規則は、コード全体の統一感に大きく影響します。
自分の書いた部分だけ別のスタイルになっていると、コードレビューや保守の際に違和感が出ます。
たとえ自分の好みと違っていても、既存コードに合わせることが実務では重要です。
C++の命名規則で特に重要なポイント
役割が分かる名前にする
C++の命名では、名前を見ただけで役割が分かることが重要です。
変数名、関数名、クラス名、定数名のそれぞれで、何を表しているのかを明確にしましょう。
一貫性を重視する
キャメルケース、パスカルケース、スネークケースのどれを使うかよりも、プロジェクト内で一貫していることが重要です。
命名スタイルが統一されていると、コードが読みやすくなり、保守もしやすくなります。
予約名を避ける
C++では、アンダースコアに関する予約名のルールに注意が必要です。
ダブルアンダースコアを含む名前、アンダースコア＋大文字で始まる名前、グローバル名前空間でアンダースコアから始まる名前は避けるべきです。
実務上は、ユーザー定義の名前で先頭アンダースコアを使わないようにすると安全です。
フレームワークの規約に合わせる
Unreal EngineやQtのように、独自の命名規則を持つフレームワークを使う場合は、そのフレームワークの規約に合わせることが重要です。
一般的なC++の慣習よりも、フレームワークのAPIや公式スタイルに合わせたほうが、コード全体の統一感を保ちやすくなります。
まとめ
C++の命名規則は、言語全体で1つに統一されているわけではありません。
プロジェクトやライブラリ、フレームワークによって、キャメルケース、パスカルケース、スネークケースなど、さまざまなスタイルが使われます。
ただし、どのスタイルを選ぶ場合でも、重要なのは「意味が分かること」「一貫していること」「予約名を避けること」です。
変数名は値の意味が分かるようにし、関数名は処理内容が分かるようにします。
クラス名や構造体名は型を表す名前として分かりやすくし、bool変数やbool関数は条件文として自然に読める名前にするとよいです。
また、C++ではアンダースコアから始まる名前やダブルアンダースコアを含む名前に注意が必要です。
メンバ変数を区別したい場合は、先頭アンダースコアではなく、末尾アンダースコアを使うほうが安全です。
新規プロジェクトでは、最初に命名規則を決めて統一することが大切です。
既存プロジェクトでは、すでに使われている命名規則に合わせることが基本です。
C++の命名規則で迷ったときは、完璧な正解を探すよりも、読み手にとって分かりやすく、プロジェクト全体で一貫した名前になっているかを重視するとよいでしょう。
以上、C++の命名規則についてでした。
最後までお読みいただき、ありがとうございました。
