命名規則 (プログラミング)

命名規則（めいめいきそく、英: naming conventions）とは、プログラミングを行う際にソースコード上の識別子（英: identifier）の名称の形式を決定するためのルールを定めるものである。ネーミング規則（きそく）、ネーミング規約（きやく）、あるいは命名規約（めいめいきやく）とも呼ばれる。通常、命名規則はソースコードの可読性や視認性の向上、プログラミング効率およびメンテナンス性の改善を目的としている。命名規則はプログラミング言語の仕様、メモリサイズなどのハードウェア的な制約、エディタや統合開発環境（IDE）の機能などに影響を受けることがある。

命名規則の重要性は、コードの一貫性と可読性を確保する点にある。一貫した命名規則を用いることで、複数の開発者が共同で作業する際にコードの理解が容易になる。また、後からコードを見直す際にも、明確な命名規則が存在することでスムーズに理解できる。このように、命名規則はビジネス上の価値をもち、ソフトウェア開発の効率化や品質向上に寄与する。

一方で、命名規則には課題や批判も存在する。過度に複雑なルールは、開発者にとって負担となりうる。また、あまりに厳格な規則は、柔軟性を欠くことがある。新しいパラダイムやフレームワークに適応するためには、命名規則も進化する必要がある。

命名規則の歴史的背景として、初期のプログラミング言語から現在に至るまで、識別子の命名方法は変遷してきた。例えば、メモリやストレージの制約が厳しかった時代には、短い識別子が好まれたが、現在では長くとも意味のある名前が推奨されることが多い。これにより、コードの可読性が向上し、バグの発見や修正が容易になる。

命名規則を考慮する際には、いくつかのポイントがある。例えば、意味のある名前を選ぶこと、一貫性を保つこと、チーム全体で合意されたルールを守ることなどが挙げられる。これらの点を考慮することで、効果的な命名規則を策定し、実践することが可能となる。

本ページでは、命名規則の定義と重要性から始め、課題と批判、歴史的背景、基本的な命名規則の紹介、命名規則の考慮すべき点、用法までを詳述する。

命名規則の定義と重要性

命名規則とは、プログラミングにおいて識別子（関数名、変数名、クラス名など）の名称の形式を決定するためのルールを定めたものである。このルールは、ソースコードの可読性やメンテナンス性の向上を目的としている。命名規則を正しく適用することで、コードの理解や保守が容易になり、開発効率が向上する。

命名規則の主な利点

命名規則を導入することで得られる主な利点は以下の通りである。

• ソースコードのドキュメント化：識別子に関する追加情報（メタデータ）を名前に含めることで、コード自体がドキュメントとして機能する。これにより、他の開発者が識別子の役割や用途を理解しやすくなる。
• 可読性の向上：統一された命名規則により、変数の使いまわしによる可読性の低下やバグの発生を防ぐことができる。命名規則はプロジェクト全体および開発チーム内で一貫性をもたせ、生産性やメンテナンス性の向上に寄与する。
• 曖昧さの回避：識別子の違いを明確にすることで、潜在的な曖昧さを回避し、誤解やミスを減らすことができる。
• ツールの利用効率向上：命名規則を守ることで、検索置換ツールでの誤操作の可能性が減り、ツールによるリファクタリングの自動化も容易になる。
• コードの見た目の美化：適切な命名規則はコードの見た目を美しくプロフェッショナルに保つことができる。短すぎる名前や長すぎる名前、可愛らしい名前や面白い名前、ローマ字や略語を避けることで、コードの一貫性と整合性が保たれる。
• 名前の衝突防止：複数のチームが開発したコードを統合・再利用する際、名前の衝突（コンフリクト）を防ぐために名前空間を適切に参照することができる。これにより、異なるチーム間での協力がスムーズに進み、プロジェクト全体の効率が向上する。

これらの理由から、命名規則はソフトウェア開発において極めて重要な要素となっている。適切な命名規則を定め、徹底することで、開発プロセス全体の品質と効率を向上させることができる。

命名規則の目的

命名規則の目的は、ソースコードの可読性を高め、保守性と一貫性を確保することである。これにより、以下のような利点が得られる。

• 理解の容易さ：明確で一貫性のある名前は、コードを読む他の開発者にとって理解しやすい。これは、新しいメンバーがプロジェクトに参加した際や、長期間放置されたコードを見直す際に特に重要である。
• バグの防止：適切な名前付けにより、関数や変数の目的が明確になり、誤使用や混乱を防ぐことができる。これにより、コードの信頼性が向上する。
• 効率的な開発：統一された命名規則により、コードの検索やリファクタリングが容易になり、開発効率が向上する。これにより、開発者はより迅速かつ正確に作業を進めることができる。
• プロジェクトのスムーズな進行：命名規則は、複数の開発者が協力して作業する際の調整を容易にし、プロジェクト全体の進行を円滑にする。これにより、コミュニケーションの齟齬や誤解を減らすことができる。
• メンテナンスの容易さ：命名規則にしたがったコードは、メンテナンスや拡張が容易であり、長期的な視点でのソフトウェアの品質を保つことができる。これにより、将来的なバグ修正や機能追加がスムーズに行える。

命名規則は、単に名前を付けるためのルールではなく、ソフトウェア開発の品質を高め、プロジェクトの成功に寄与する重要な要素である。適切な命名規則を策定し、それを徹底することで、開発プロセス全体の効率と品質を向上させることができる。

ビジネス上の価値

ソフトウェアシステムやアプリケーションソフトウェアのエンドユーザーが識別子名の良し悪しを意識することはほとんどない。ソースコード上の識別子名は、通常ユーザインタフェースに表出することはないからである。しかし、システムを引き継いでいく他の開発者やアナリストにとっては、識別子が適切に選定されていることで、システムが何を行っているのかを理解したり、さらには新たな需要に応じてソースコードをどのように修正・拡張すればよいかを判断したりすることが極めて容易となる。

例えばC言語による例として、

double a, b, c;
b = 160.0;
c = 1500.0;
a = b * c;

というコードは文法的に間違っているわけではないが、その意味や意図は見当もつかず、どのようにも解釈することができる。少なくともコメントがなければ、各変数が何を意味しているのか、また計算式が何を意味しているのかは理解できない。

これに対して、

double monthly_pay_jpy, hours_worked, hourly_pay_jpy;
hours_worked = 160.0;
hourly_pay_jpy = 1500.0;
monthly_pay_jpy = hours_worked * hourly_pay_jpy;

というコードは、各変数名に意味をもつ名前が用いられていることで、例えコメントがなくとも、少なくともシステムやアプリケーションの基本的な前後関係を理解していれば、意味や意図が分かりやすくなる（monthly_pay_jpy = 月給[円]、hours_worked = 勤務時間、hourly_pay_jpy = 時給[円]）。

また、各種APIや外部で開発されたサードパーティー製のライブラリを利用する場合も、適切な命名規則に基づいて整理されたAPI・ライブラリの方が機能を類推しやすくなるため（インタフェース自体がマニュアルとなる）、生産性が向上する。

ソースファイルや、そのソースファイルを配置するディレクトリの命名規則もまた重要である。適切な命名と分類・階層化を行うことで、どのファイルにどのような機能が実装されているのか、ということが分かりやすくなり、メンテナンス性の向上に繋がる。C++やC#のようなクラスベースのオブジェクト指向プログラミング言語では、一般的にそのソースファイル内で記述される主要なクラスの名前をファイル名とすることが多い。Javaの場合は最上位（トップレベル）のpublicクラスを定義するソースファイルの名前は、そのクラスの名前と同じでなければならないという言語仕様上の制約が存在する。

C/C++のライブラリは、モジュールと共に関数宣言や型定義を含むヘッダーファイルを公開インタフェースとして提供することが多く、ヘッダーファイルの命名規則も重要となる。

命名規則の課題と批判

命名規則はソフトウェア開発において多くの利点を提供する一方で、いくつかの課題や批判も存在する。以下に、主な課題とそれに対する批判を挙げる。

過度な複雑さ

命名規則が複雑すぎると、開発者にとって負担となる可能性がある。厳格なルールに従わなければならない場合、開発者はコーディングに時間を費やすだけでなく、命名規則を理解し、遵守するためにも時間を割かなければならない。これにより、開発のスピードが低下することがある。

柔軟性の欠如

あまりに厳密な命名規則は、開発者の創造性や柔軟性を制約することがある。特に、新しいパラダイムやフレームワークに適応する際に、既存の命名規則が障害となる場合がある。これにより、新しい技術の導入やイノベーションが妨げられる可能性がある。

規則の一貫性と適用の困難さ

プロジェクトが大規模になるにつれて、命名規則を一貫して適用することが難しくなることがある。複数のチームや多数の開発者が関与するプロジェクトでは、命名規則が守られないことがある。このような状況では、一貫性が失われ、コードの可読性やメンテナンス性が低下する。

過度な規制と開発者のストレス

厳格な命名規則は、開発者にとって過度なストレスとなることがある。ルールを厳密に守る必要があるため、自由にコードを書くことが難しくなり、開発者のモチベーションが低下することがある。これにより、チーム全体の生産性が影響を受ける可能性がある。

進化する技術への対応

技術が進化する中で、既存の命名規則が新しい技術やフレームワークに適応できない場合がある。例えば、新しいプログラミング言語やライブラリが登場した際に、従来の命名規則が適用できない場合がある。このような場合には、命名規則を見直し、適応させる必要がある。

命名規則の設定と管理のコスト

命名規則を設定し、維持するためには時間とリソースが必要である。プロジェクトの初期段階で命名規則を策定し、ドキュメント化する必要がある。また、新しいメンバーがプロジェクトに参加する際には、命名規則を学習し、適用するためのトレーニングが必要となる。

これらの課題や批判を踏まえ、命名規則を効果的に活用するためには、バランスの取れたアプローチが必要である。過度に厳格なルールを避け、適度な柔軟性をもたせることで、開発者が快適に作業できる環境を整えることが重要である。また、定期的に命名規則を見直し、プロジェクトの進行や技術の進化に合わせて適応させることが求められる。

命名規則の歴史的背景

命名規則の歴史は、プログラミングの歴史と密接に関連している。初期のコンピュータプログラミングにおいては、ハードウェアの制約やメモリ容量の限界が大きな影響を及ぼし、短く簡潔な名前が好まれていた。しかし、技術の進化と共に、命名規則も変遷を遂げ、現在の形に至るまでに様々な変革を経てきた。

初期の命名規則（1950年代〜1960年代）

コンピュータプログラミングの黎明期には、パンチカードや初期のアセンブリ言語が使用されていた。この時期には、メモリやストレージの容量が極めて限られていたため、識別子の名前は1～2文字程度の短いものが多かった。例えば、FORTRANやCOBOLなどの初期のプログラミング言語では、変数名は通常6文字以内に制限されていた。

中期の発展と命名規則の多様化（1970年代〜1980年代）

1970年代から1980年代にかけて、C言語やPascalなどのプログラミング言語が登場し、命名規則もより柔軟に、かつ多様化した。この時期には、識別子の名前にアルファベットだけでなく数字やアンダースコア_も使用できるようになり、名前の長さに関する制約も緩和された。さらに、一部の言語では、ハイフンマイナス-やドット.が識別子の名前に使用できるようになり、表現の幅が広がった。例えば、LISPではハイフンマイナス-がよく使用され、Smalltalkではドット.がメソッドチェーンの区切りとして利用された。

オブジェクト指向プログラミングの影響（1990年代）

1990年代には、オブジェクト指向プログラミング（OOP）の普及により、命名規則も大きな影響を受けた。OOPの概念に基づき、クラス名や関数名には、より意味のある名前が求められるようになった。この時期には、「PascalCase」の形式（この時点では名前は付いていない）が一般化し、識別子の形式に関する標準が確立されつつあった。これにより、コードの一貫性と可読性が向上した。

現代の命名規則とその進化 (2000年代〜現在)

2000年代に入り、Microsoftの.NETの登場と共に「camelCase」や「PascalCase」といった具体的な命名規則が広く普及した。これにより、識別子の形式に関する標準化がさらに進み、コードの一貫性と可読性が一層向上した。現在では、PythonやJavaScriptなどのモダンなプログラミング言語が広く使用されており、それぞれの言語で推奨される命名規則が存在する。また、ソフトウェア開発の規模が拡大し、グローバルな開発チームが協力するプロジェクトが増える中で、命名規則の重要性はさらに高まっている。

命名規則は、言語の特性やプロジェクトの要件に応じて進化し続けている。例えば、PythonではPEP 8というスタイルガイドが推奨されており、JavaScriptではAirbnbのスタイルガイドが広く参照されている。これらのスタイルガイドは、命名規則だけでなく、コード全体のスタイルに関する詳細な指針を提供している。

しかし、命名規則の形式的な標準化は定着しつつあるが、その呼び方には未だにばらつきがあり、各形式毎の国際標準といえる呼び方は存在していない。

基本的な命名規則

名称	英語表記	説明	表記例
スネークケース	snake case	単語間をアンダースコア（_）で繋ぐ形式。	example_variable
スクリーミングスネークケース	screaming snake case	単語間をアンダースコア（_）で繋ぎ、全て大文字にする形式。「アッパースネークケース（upper snake case）」や「コンスタントケース（constant case）」とも呼ばれる。	EXAMPLE_VARIABLE
キャメルケース	camel case	各単語の頭文字を大文字にし、単語を連結する形式（最初の単語のみ頭文字が小文字）。.NETの文脈で使用。	exampleVariable
ローワーキャメルケース	lower camel case	キャメルケースと同じ形式だが、フレームワークや言語に依存しない表現。	exampleVariable
パスカルケース	Pascal case	各単語の頭文字を大文字にし、単語を連結する形式（キャメルケースと似ているが、最初の単語の頭文字も大文字）。.NETの文脈で使用。	ExampleVariable
アッパーキャメルケース	upper camel case	パスカルケースと同じ形式だが、フレームワークや言語に依存しない表現。	ExampleVariable
ケバブケース	kebab case	単語間をハイフン（-）で繋ぎ、各単語の頭文字を小文字にする形式。 「チェインケース / チェーンケース（chain case）」とも呼ばれる。	example-variable
トレインケース	train case	単語間をハイフン（-）で繋ぎ、各単語の頭文字を大文字にする形式。	Example-Variable
ドットケース	dot case	単語間をドット（.）で繋ぐ形式。	example.variable

命名規則の考慮すべき点

命名規則は実際には、開発する対象や環境に依存する。しかし、多くの命名規則に共通に見られる要素がいくつか存在する。

識別子の長さ

命名規則の最も基本的な規則のうちの一つは、識別子の長さに関するものである（長さの限度および識別子に使える文字の種類）。数値を挙げて上限を設定する場合もあれば、より緩和的なガイドラインを設定する場合もある。

識別子長の規則は議論の的になりやすく、学術的な議論にもなっている。適切な長さはケースバイケースであり、一概には決まらない。

以下に考慮すべき点を挙げる。

• 短さ：タイピングしやすいため、短い識別子が好まれる傾向がある。ただし統合開発環境（IDE）の入力支援機能（コード補完）を利用可能な場面では、あまり問題とならない。ただし、あまりにも短い識別子（a や i など）は、識別が困難である。
• 理解のしやすさ：短い識別子では暗号的な名前になるなど、意味を充分にもたせられないとして、長い識別子が好まれる場合もある。
• 長すぎない：長い識別子は画面上に占める面積が増え、コード全体を素早く読めなくなることから、好まれない場合がある。
• 区別のしやすさ：例え長い識別子を使っても、そのうち1文字しか差異がない二つの識別子などは一見して区別が困難である。
• 略語の使用可否：略語は混乱を招きやすいため控えた方がよいが、長すぎる正式名称も可読性を損なう。
• スコープ毎の調整：変数や関数のスコープに応じて識別子の長さを変えることもある。スコープが広い場合（グローバル検索しやすく名前衝突しにくい）は長い名前が好まれることもあるが、スコープが狭い場合は短い名前でも構わない、など。

初期のリンケージエディタには、メモリ使用量を抑えるために変数名などを6文字以内に制限していたものがあり、そのために古いプログラムで識別子が短く制限されていたという歴史もある。後発のプログラミング言語および処理系でも、識別子の長さに制限が設けられている場合があるが、実用的な範囲では通例問題にならない上限である。

大文字・小文字と数字

命名規則によっては、大文字と小文字の使い方を制限しているものもある。例えば、特定の識別子においては全ての単語を大文字で始めなければならない規則や、逆に小文字で始めることが求められる規則がある。これにより、識別子の一貫性と可読性が向上し、コードの構造がより明確になる。

また、大文字も小文字も使えるが、それらに意味を与える場合もある。例えば、「camelCase」や「PascalCase」といった命名規則では、大文字と小文字を組み合わせて使用することで、識別子の読みやすさを高めている。camelCaseでは、最初の単語を小文字で始め、続く単語の頭文字を大文字にする。一方、PascalCaseでは、全ての単語の頭文字を大文字にする。これにより、単語の境界が視覚的に明確になり、識別子がより直感的に理解できるようになる。

アルファベット、数字、これらを混合した英数字の使い方を指定する命名規則もある。例えば、一部の命名規則では、識別子の先頭に数字を使用することを禁止している。具体的には、PythonやJavaでは、関数名や変数名の先頭に数字を使用することは許可されていない。

プログラミング言語によっては大文字と小文字を区別しないものもある。例えば、SQLや一部の古いプログラミング言語では、大文字と小文字が区別されず、識別子の名前はケースインセンシティブ（英: case-insensitive）である。これに対して、PythonやJava、C++などの現代的なプログラミング言語では、大文字と小文字が区別され、同じ名前でも異なるケース（大文字・小文字）をもつ識別子は別のものとして扱われる。これにより、識別子の命名においてより多くの選択肢が提供され、詳細な意味をもたせることが可能になる。

複数の単語からなる識別子

一般に「意味のある識別子」が推奨される。一つの単語では意味が分かりにくい場合もあり、複数の単語を識別子に使用することになる。結果として、命名規則には、複数の単語を連結する場合の方法が指定されることになる。これには、各プログラミング言語で定められている予約語（キーワード）と名前衝突しにくくなる効果もある。

単語境界の表し方

多くのプログラミング言語は識別子内にスペース が存在することを許さない。そのため、スペース 以外で単語の区切りを示す方法が必要となる（区切りを示さないと、可読性が低下するため）。

区切り記号による単語の連結

英数字で記された単語を特定の区切り文字（デリミタ）で連結する。一般に、この目的で使われる文字は、ハイフンマイナス-かアンダースコア_である（例えば、「two words」であれば two-words や two_words と記述する）。ハイフンマイナス-はCOBOLやLISPでよく用いられる。Cascading Style Sheetsでもプロパティ名にハイフンマイナス-が使われることが多い。他の言語（C言語やPascal系など）はハイフンマイナス-が減算を表すため、識別子には用いることができない。区切り文字で連結された文字列が蛇や鎖のように見えることから、スネークケースやチェーンケースと呼ばれることもある。

大文字/小文字による単語の切り分け

単語の頭文字を大文字、それ以外を小文字にする。例えば、「two words」は twoWords や TwoWords と記述する。これをキャメルケース（ローワーキャメルケース、アッパーキャメルケース）などと呼ぶこともある。アッパーキャメルケースはPascalで利用されていた経緯から、パスカルケースと呼ばれることもある。

メタデータと命名規則

命名規則は、特定のプロジェクトや問題領域に必要なルールを定めるだけでなく、ソフトウェアアーキテクチャの原則や使用するプログラミング言語、プロジェクト全体に渡る方法論を反映する大きな枠組みを提供することもある。

COMインタフェース名のI接頭辞（プレフィックス）など、ソフトウェアフレームワークによってルールが定められているものもある。

ハンガリアン記法

最もよく知られている命名規則としてハンガリアン記法 (英: Hungarian notation) がある。これには、「目的」を名前に含める方式（アプリケーションハンガリアン）と、「データ型」を名前に含める方式（システムハンガリアン）に分けられる。

桁位置に意味をもたせる記法

非常に短い（8文字以下）長さで識別子を形成する場合、桁位置毎に意味をもたせることがある。例えば、「LCCIIL01」という名前で、先頭の「LC」は「信用状（英: letter of credit）、次の「C」はCOBOL、「IIL」は特定のプロセスサブセットを表し、「01」がシーケンス番号となっている。

このような規則はメインフレームでのJCLなどで今でも使われている。また、MS-DOSでのファイル名（8文字＋拡張子3文字という制限がある）でも見られる。

単語連結法（OF Language）

初期の命名規則として、IBMが1980年代にIMS（Information Management System）のマニュアルで採用した「OF Language」がある。

これは、PRIME-MODIFIER-CLASS（主要部-修飾部-クラス）の形式で、例えば「CUST-ACT-NO」という名前で「customer-account-number（顧客-口座-番号）」を表す。

PRIMEの単語は、システムが対象とする主な実体を指す。MODIFIERの単語は、補助的な具体化をしたり、可読性を向上させる役目をもつ。CLASSの単語は理想的にはデータ型を表す短いリストである。典型的なCLASS単語として、NO（number）、ID（identifier）、TXT（text）、AMT（amount）、QTY（quantity）、FL（flag）、CD（code）、W（work）などがある。実際、CLASS単語としては2ダースほどの単語がリストアップされている。

CLASS単語は一般に右端（接尾辞）に置かれ、ハンガリアン記法（システムハンガリアン）の接頭辞と同じ役割を果たしている。

CLASS単語の目的は、一貫性を保つだけでなく、プログラマーにデータフィールドのデータ型を指示する意味がある。BOOLEAN（two values only）が登場するまでは、FL（flag）が二値のみを取るフィールドを示していた。

用途別の一般的な命名規則

命名規則は、コードの可読性や一貫性を保つために重要であり、特定の用途毎に異なる規則が適用される。以下に、関数名、変数名、クラス名、コンスタント名、パッケージ名、ファイル名の一般的な命名規則について説明する。

関数名

関数名は、関数の動作や目的を明確に示すものでなければならない。一般的には、動詞や動詞句を用いて命名し、ローワーキャメルケースやスネークケースがよく使用される。例えば、Pythonではスネークケース（例：calculate_total）、JavaやJavaScriptではローワーキャメルケース（例：calculateTotal）が推奨される。また、関数名は短く簡潔であることが望ましいが、機能を正確に伝えるために必要な場合は長い名前も許容される。

変数名

変数名は、その変数が保持するデータや目的を明確に表現する必要がある。一般的には、名詞や名詞句を用いて命名し、関数名と同様にローワーキャメルケースやスネークケースが使用される。例えば、Pythonではスネークケース（例：user_name）、JavaやJavaScriptではローワーキャメルケース（例：userName）が推奨される。変数名も短く簡潔であることが望ましいが、意味を失わない目的で長い名前も許容される。

クラス名

クラス名は、クラスが表すオブジェクトや概念を明確に示すものでなければならない。一般的には、名詞や名詞句を用いて命名し、アッパーキャメルケース（パスカルケース）が推奨される。例えば、JavaやC#ではアッパーキャメルケース（例：CustomerAccount）が一般的である。クラス名は、一目でクラスの役割や目的が理解できるようにすることが重要である。

コンスタント名（定数）

コンスタント名は、その定数が表す値や意味を明確に示すものでなければならない。一般的には、全ての単語を大文字で表記し、単語間をアンダースコア_で区切るスクリーミングスネークケースが使用される。例えば、PythonやJavaでは、MAX_VALUEやDEFAULT_TIMEOUTといった命名が推奨される。これにより、定数と変数を視覚的に区別しやすくなる。

パッケージ名

パッケージ名は、パッケージが含むクラスやモジュールの機能や役割を示すものでなければならない。一般的には、全ての単語を小文字で表記し、単語間をドット.で区切るドットケースが使用される。例えば、Javaでは、com.example.projectのように命名する。パッケージ名は一意であることが求められるため、通常は逆ドメイン名を使用する。

ファイル名

ファイル名は、そのファイルが含むコードやリソースの内容を明確に示すものでなければならない。一般的には、クラス名やモジュール名に一致させることが多い。例えば、Javaではクラス名と同じファイル名（例：CustomerAccount.java）、Pythonではモジュール名と同じファイル名（例：user_profile.py）が推奨される。ファイル名はシンプルで一貫性があることが重要である。

これらの一般的な命名規則を遵守することで、コードの可読性と一貫性が向上し、メンテナンス性が高まる。

プログラミング言語毎の命名規則の違い

C/C++

C言語とC++は共に大文字・小文字を区別する言語だが、キーワードや標準ライブラリ（標準Cライブラリ、標準C++ライブラリ）の識別子の多くは小文字である。C++の設計者Bjarne Stroustrupは、言語組み込みの型および標準ライブラリの型と、ユーザー定義の型を区別できるように、ユーザー定義の型の名前は大文字で始めることを推奨している。また、全ての文字を大文字にした名前は、慣例的にプリプロセッサマクロでの使用に予約されているので、マクロシンボルではない識別子の名前には絶対に使用してはいけないと助言している。

C言語の場合、次の名前が実装系（コンパイラおよび標準ライブラリ）のために予約されている。

• グローバルスコープを持ち、_で始まる名前。
• _で始まり、その次が大文字の名前。
• __で始まる名前。

C++の場合、次の名前が実装系のために予約されている。

• グローバルスコープを持ち、_で始まる名前。
• _で始まり、その次が大文字の名前。
• __を含む名前。

予約された名前をユーザー定義の識別子に利用した場合は未定義動作となるため、ユーザー定義の識別子に使ってはならない（例えば、__reservedや_Reserved、ファイルスコープの_reservedなど）。

ライブラリおよびプロジェクト固有の命名規則

C言語は名前空間をサポートしないため、代わりに各種APIの関数や型、定数シンボルには固有の接頭辞（プレフィックス）を付けて、名前衝突を防いだり判別しやすくしたりすることがある（例えばOpenGLのgl/GL/GL_など）。

定数名を表す際に、数学や自然科学などにおける定数のアナロジーから、k接頭辞を用いるルールも存在する。少数派だが、列挙型のメンバー（列挙定数）にe接頭辞を用いているプロジェクトも存在する。

Smalltalk

Smalltalkでは、大域変数（クラスも大域変数であるため、クラス名も含む）は大文字から始まるアッパーキャメルケース、局所変数、メンバーとなる変数は小文字からはじまるローワーキャメルケースを使用する。これは、言語仕様でも決まっており、存在しない大文字で始まる変数を参照するコードを書いても翻訳時にエラーとはならないが、存在しない小文字の変数を参照するコードを書いていると翻訳時にエラーとなる。また、メソッドが存在するセレクター（関数名のようなもの）は、小文字で始まるローワーキャメルケースを使い、メソッドが存在しないセレクターには大文字で始まるアッパーキャメルケースを用いることが慣習になっている。これは、名前空間の解決等でメソッドが存在しないセレクターを使おうとしたとき、基底クラス等にメソッドが存在するとメソッドを呼んでしまうためである。後発のJavaなどはこの規則を強く継いでいる。ただし、Smalltalkにはプリプロセッサは存在しないため、全て大文字の識別子を使う慣習は存在しない。

Java

Javaでは、言語仕様および標準ライブラリの設計時点から、クラスや関数、定数や変数などの命名における大文字・小文字の使い分けといった規則が決められている。例えば、クラス名は大文字で始めるアッパーキャメルケース、関数名や変数名は小文字で始めるローワーキャメルケース、また定数名は全て大文字でアンダースコア_区切りとする、などである。

JavaBeansからの影響を発端として、特定の接頭辞を付けたアクセッサメソッド（getter/setter）が定義され、カプセル化に利用されることも多い。

class SomeWidget {
    private String caption;
    private boolean visible;

    public String getCaption() { return this.caption; }
    public void setCaption(String caption) { this.caption = caption; }
    public boolean isVisible() { return this.visible; }
    public void setVisible(boolean visible) { this.visible = visible; }
}

なお、Java 9ではアンダースコア_のみの識別子は予約語（予約済みのキーワード）となったため、ユーザーコードで識別子として使用することはできなくなった。

Java Native Interface（JNI）において、Java側でnativeキーワードを付けて宣言された関数に対応するネイティブコード側の実装関数名は、特定の命名規則に従う必要がある。これにより、所属するパッケージ（名前空間）とクラスを処理系が正しく解決できるようになる。

具体的には、JNI関数の名前は以下の形式に従う必要がある。

Java_<Fully_Qualified_Class_Name>_<Method_Name>

ここで、<Fully_Qualified_Class_Name>は、パッケージ名とクラス名をアンダースコア_で区切ったものであり、<Method_Name>はJava側で宣言された関数の名前を示す。例えば、パッケージcom.exampleに属するクラスMyClass内で宣言されたnative関数doSomethingに対応するネイティブ関数名は次のようになる。

JNIEXPORT void JNICALL Java_com_example_MyClass_doSomething(JNIEnv *, jobject);

具体的な命名規則の詳細

1. パッケージ名とクラス名の結合
   • パッケージ名とクラス名は、アンダースコア_で結合する。
   • ドット.は全てアンダースコア_に置き換えられる。
2. クラス名とメソッド名の結合
   • クラス名とメソッド名も、アンダースコア_で結合する。
3. 特殊文字のエスケープ
   • Javaのクラス名や関数名に含まれる特殊文字はエスケープされる。
   • 例えば、アンダースコア_自体は_1、ドル記号$は_00024としてエスケープされる。

BASIC、Visual Basic、VB.NET

BASICはC言語と違い、大文字・小文字の区別をしない言語である。処理系は大文字・小文字の違いを無視してシンボルの識別をしている。これはVisual Basic（VBAを含む）およびVisual Basic .NETにおいても受け継がれている。したがって、例えばform.show、Form.Show、FORM.SHOW は全て同じ意味になる。ただし、識別子名は人間にとって読みやすい方が好ましいため、VB/VB.NETでは通例シンボルの宣言時に大文字・小文字を使い分け、シンボルを利用する際も宣言に応じて区別する命名規則が採用される（統合開発環境によるコード補完や自動フォーマットの際も宣言名が利用される）。型名や関数名、プロパティ名は大文字で始めるアッパーキャメルケースが採用されている。

かつてVB/VBAでは、GUI要素（コントロール）などの変数名に、略語の接頭辞（ハンガリアン記法）を用いる命名規則が推奨されていたが、VB.NET（Windows FormsおよびWPFなど）ではそのようなガイドラインは存在せず、ハンガリアン記法は非推奨となっている。

Delphi（Object Pascal）

Delphi言語は、PascalおよびVB系の言語と同様、大文字・小文字の区別を行なわないが、下記の命名規則が推奨されている。

• レコード型、オブジェクト型、クラス型、およびtypeキーワードによる型のエイリアスなど、型を表すシンボルは'T'で始める。
• インタフェース型名は'I'で始める。
• クラスのフィールド名は'F'で始める。
• ルーチン名、メソッド名は大文字で始めて、大文字で単語を区切るアッパーキャメルケース。

C#

C#言語および.NET Frameworkは、元々Delphiの文法や言語機能およびVCLがベースになっていることもあり、Microsoftによる標準的な命名規則も（C/C++よりはむしろ）Delphiに似たものを踏襲している。

C#はC/C++やJava同様に大文字・小文字を区別するが、VB.NETを始めとする他の言語との相互運用性の観点から、大文字・小文字の違いのみのシンボル群をAPI外部に公開することは避けるべきとされている。

Objective-C

AppleによるObjective-CおよびCocoaの命名規則に関するドキュメントのアーカイブが公開されている。クラス、プロトコル、インスタンス変数、メソッド、プロパティ、定数、関数、略語などに関する基本的な命名ガイドラインが網羅されており、Apple製のソフトウェアフレームワークの多くがこのガイドラインに基づいている。

Swift

SwiftのAPI設計ガイドラインがswift.orgで公開されており、命名規則に関するルールも述べられている。SwiftはObjective-Cとの相互運用が可能であり、特定の命名規則に従うことで自動的に名前を変換する仕組みも用意されている。

以下に、具体的な例を用いて説明する。

Objective-Cの列挙型の変換

Objective-Cで定義された列挙型は、NS_ENUMマクロやNS_OPTIONSマクロを用いることで、Swiftにおいて自動的に適切な列挙型として変換される。

例えば、次のObjective-Cのコード：

typedef NS_ENUM(NSInteger, RPSMove) {
    RPSMoveRock,
    RPSMovePaper,
    RPSMoveScissors
};

このObjective-Cの列挙型は、Swiftでは次のように変換される：

enum RPSMove: Int {
    case rock
    case paper
    case scissors
}

このように、Objective-CのRPSMoveRock、RPSMovePaper、RPSMoveScissorsは、それぞれSwiftのrock、paper、scissorsに変換される。これにより、Swiftの開発者はSwiftのスタイルに合った方法でこれらの列挙型を使用することができる。

C/C++の組み込み型との互換性

Swiftには、C/C++の組み込み型と互換性のある型も用意されている。これらの型は、名前がCで始まることで識別される。

例えば、次のようなCの構造体があるとする：

struct MyStruct {
    int a;
    double b;
};

この構造体は、Swiftでは次のように変換される：

struct CMyStruct {
    var a: Int32
    var b: Double
}

SwiftのCMyStructは、CのMyStructと互換性があり、SwiftのコードからもCのコードからも使用することができる。

これらの命名規則と変換の仕組みにより、SwiftとObjective-C、C/C++の間でスムーズな相互運用が可能となり、開発者はそれぞれの言語の強みを活かしつつ、効率的にコードを統合することができる。SwiftのAPI設計ガイドラインは、このような相互運用性を考慮した命名規則を提供しており、開発者が一貫性のある、理解しやすいコードを記述するのに役立つ。

命名規則のベストプラクティス

命名規則は、ソフトウェア開発においてコードの可読性、一貫性、メンテナンス性を向上させるために重要な役割を果たす。以下に、効果的な命名規則を確立し、維持するためのベストプラクティスをいくつか紹介する。

意味のある名前を選ぶ

命名規則の基本は、識別子に意味のある名前を付けることである。名前は、その関数や変数、クラスが何を表しているか、どのような役割を果たしているかを明確に示すべきである。例えば、変数名に「temp」や「data」といった曖昧な名前を使用することは避け、「userAge」や「transactionAmount」といった具体的な名前を選ぶことが推奨される。

一貫性を保つ

一貫性は命名規則の重要な要素である。プロジェクト全体を通じて、同じ命名規則を使用することで、コードの可読性が向上する。例えば、変数名にローワーキャメルケースを使用する場合は、全ての変数名でこの形式を維持する。関数名、クラス名、コンスタント名についても同様に一貫性を保つことが重要である。

アブリビエーションの使用に注意

略語や省略形を使用する際は、注意が必要である。一般的で広く理解されている略語を使用することは問題ないが、プロジェクト内で一貫して使用されていない略語や、意味が曖昧な略語は避けるべきとされる。例えば、「msg」や「num」は一般的に理解されるが、特定のプロジェクトやチームでのみ通用する略語は避けた方がよい。

長さのバランス

名前の長さは、簡潔さと明確さのバランスを取ることが重要である。名前が短すぎると意味が曖昧になり、長すぎると可読性が低下する。適切な長さの名前を選び、必要に応じて補足的なコメントを付け加えることで、コードの理解を助けることができる。

ドキュメント化

命名規則を文書化し、プロジェクト全体で共有することが重要である。ドキュメントには、使用する命名規則、略語のリスト、特定の命名規則に関するガイドラインなどを含める。これにより、新しいチームメンバーがプロジェクトに参加する際に、命名規則を迅速に理解し、適用することができる。

レビューとフィードバック

命名規則を効果的に適用するためには、コードレビューとフィードバックが不可欠である。チーム全体で命名規則を遵守し、問題が発生した場合には迅速に修正するための仕組みを整える。定期的なコードレビューを通じて、命名規則の一貫性を保ち、必要に応じて規則を見直すことが重要である。

コーディングスタイルガイドの活用

多くのプログラミング言語やフレームワークには、公式のスタイルガイドが存在する。これらのスタイルガイドは、命名規則を含む様々なコーディングルールを提供しており、これに従うことで、広く認知されたベストプラクティスを取り入れることができる。例えば、PythonではPEP 8、JavaScriptではAirbnbのスタイルガイドが広く使用されている。

これらのベストプラクティスを遵守することで、命名規則の一貫性と品質を保ち、ソフトウェア開発の効率とメンテナンス性を向上させることができる。

命名規則のツールとリソース

命名規則を効果的に実践し、維持するためには、適切なツールとリソースを活用することも重要である。以下に、命名規則の遵守を支援するための主要なツールとリソースを紹介する。

コードリンティングツール

コードリンティングツールは、コードの静的解析を行い、命名規則やコーディングスタイルの違反を検出するツールである。これらのツールは、開発プロセスの早い段階で問題を指摘し、修正を促すことで、コードの一貫性と品質を保つのに役立つ。主なコードリンティングツールには以下のようなものがある。

• ESLint（JavaScript）：JavaScriptコードの静的解析ツールで、カスタマイズ可能なルールセットを使用して命名規則をチェック可能。
• Pylint（Python）：Pythonコードの静的解析ツールで、PEP 8に準拠したコーディングスタイルをチェックする機能をもつ。
• Checkstyle（Java）：Javaコードの静的解析ツールで、コーディングスタイルや命名規則の違反を検出する。
• Rubocop（Ruby）：Rubyコードの静的解析ツールで、命名規則やコーディングスタイルのチェックを行う。

統合開発環境（IDE）のサポート

多くの統合開発環境（IDE）には、命名規則の遵守を支援する機能が組み込まれている。これらの機能を活用することで、コードの一貫性を保ち、命名規則の違反を未然に防ぐことができる。主なIDEには以下のようなものがある。

• Visual Studio Code：多数の拡張機能が利用可能で、ESLintやPylintなどのリンティングツールと統合することができる。
• IntelliJ IDEA：コーディングスタイルの設定を細かくカスタマイズでき、命名規則のチェック機能も充実している。
• PyCharm：Python向けのIDEで、PEP 8に準拠したコーディングスタイルチェック機能を備えている。
• Eclipse：Java向けのIDEで、Checkstyleとの統合が可能であり、命名規則のチェックを行うことができる。

スタイルガイドとドキュメント

各プログラミング言語やフレームワークには、公式のスタイルガイドや命名規則に関するドキュメントが存在する。これらのガイドラインに従うことで、広く認知されたベストプラクティスを取り入れることができる。主なスタイルガイドには以下のようなものがある。

• PEP 8（Python）：Pythonの公式スタイルガイドで、命名規則やコードフォーマットに関する詳細なガイドラインを提供する。
• Airbnb JavaScript Style Guide：JavaScriptのコーディングスタイルガイドで、命名規則やベストプラクティスを網羅している。
• Google Java Style Guide：Javaのコーディングスタイルガイドで、命名規則やコードフォーマットに関する指針を提供する。
• Swift API Design Guidelines：Swiftの公式スタイルガイドで、命名規則やAPI設計に関する詳細なガイドラインを提供する。

コミュニティリソース

オープンソースコミュニティや開発者フォーラムも、命名規則に関する有益なリソースを提供している。これらのリソースを活用することで、他の開発者の経験や知見を取り入れ、自分のプロジェクトに適用することができる。主なコミュニティリソースには以下のようなものがある。

• GitHub：多くのオープンソースプロジェクトがホストされており、プロジェクトのコーディングスタイルや命名規則を参照できる。
• Stack Overflow：開発者同士のQ&Aサイトで、命名規則に関する質問や回答が多数投稿されている。
• Reddit（r/programming）：プログラミングに関するディスカッションフォーラムで、命名規則に関する議論や提案が行われている。

これらのツールとリソースを活用することで、命名規則の一貫性を保ち、プロジェクト全体の品質と効率を向上させることができる。

脚注

関連項目

• 識別子
• 名前空間

外部リンク

• Javaコーディング規約 - 第3回：ネーミング規約（前編） (1/3) ThinkIT、2005年9月7日。
• 生産性と保守性を高めるコーディング規約の実際---目次 | 日経クロステック（xTECH）
• C# のコーディング規則 (C# プログラミング ガイド) | Microsoft Docs：命名規則