命名規則（プログラミング）

コンピュータプログラミング において、命名規則とは、ソースコードやドキュメント内の変数、型、関数、その他のエンティティを示す識別子に使用される文字シーケンスを選択するための一連の規則です。

命名規則を使用する理由 (プログラマーが任意の文字シーケンスを選択できるようにするのではなく) には、次のものがあります。

• ソースコードを読んで理解するために必要な労力を軽減するため。^[1]
• コードレビューが構文や命名標準よりも重要な問題に集中できるようにします。
• コード品質レビュー ツールが、構文やスタイルの設定以外の重要な問題に主にレポートを集中できるようにします。

命名規則の選択は議論の余地のある問題であり、それぞれの党派が自分たちのものが最良であり、他は劣っていると主張します。口語的には、これは教義の問題であると言われています。^[2]多くの企業が独自の規則を確立しています。

命名規則の利点は次のとおりです。

• 識別子の使用に関する追加情報（メタデータなど）を提供する。
• 開発チーム内での期待を形式化し、一貫性を促進するのに役立ちます。
• エラーの可能性を最小限に抑えながら、自動リファクタリングや検索・置換ツールを使用できるようにする。
• 曖昧さが潜在する場合に明確さを高めるため。
• 作業成果物の美観とプロフェッショナルな外観を高めるため（たとえば、長すぎる名前、滑稽な名前や「かわいい」名前、略語を禁止するなど）。
• 異なる組織の作業成果物を組み合わせたときに発生する可能性のある「名前の衝突」を回避するのに役立ちます (名前空間も参照)。
• プログラムのソースコードとすべての関連文書の提出を必要とするプロジェクトの引き継ぎで使用するための有意義なデータを提供する。
• 長い期間を経てコードを再利用する場合に、より理解しやすくなるようにするため。

命名規則の選択 (およびそれがどの程度適用されるか) は、しばしば論争の的となる問題であり、党派によって自分の見解が最良で、他の見解が劣っているという主張が交わされます。さらに、よく知られた明確に定義された命名規則があっても、組織によっては一貫してそれに従わない場合があり、矛盾や混乱が生じます。命名規則のルールが内部的に矛盾していたり​​、恣意的であったり、覚えにくかったり、あるいは有益というよりは負担が大きいと認識されていたりすると、こうした問題が悪化する可能性があります。

適切に選択された識別子により、開発者やアナリストは、システムの動作を理解しやすくなり、新しいニーズに合わせて ソース コードを修正または拡張する方法も大幅に容易になります。

例えば、

 ａ＝ｂ＊ｃ；    

文法的には正しいが、その目的は明らかではない。これと比較すると次のようになる。

 週払い=労働時間*時給;    

これは、少なくとも文の文脈に精通している人にとっては、ソースコードの意図と意味を暗示します。

実験によれば、識別子のスタイルは想起と精度に影響を及ぼし、スタイルに慣れると想起が速くなることが示唆されている。^[3]

命名規則の正確なルールは、それが使用されるコンテキストによって異なります。ただし、現在一般的に使用されている命名規則のほとんど、あるいはすべてに影響を与える共通要素がいくつかあります。

すべての命名規則の基本要素は、識別子の長さ(つまり、識別子に許可される個々の文字の有限数)に関連する規則です。一部の規則では固定の数値制限が規定されていますが、その他の規則ではそれほど正確ではないヒューリスティックやガイドラインが指定されています。

識別子の長さのルールは実際には頻繁に争われており、学術的にも多くの議論の対象となっています。

考慮すべき点:

• 短い識別子の方が入力しやすいため、より便利であると考えられる（ただし、多くの IDE やテキストエディタはテキスト補完機能を提供しており、この問題は軽減される）。
• 非常に短い識別子（「i」や「j」など）は、自動検索および置換ツールを使用して一意に区別することが非常に困難です（ただし、正規表現ベースのツールでは問題になりません）。
• 短い識別子では十分な情報をエンコードできなかったり、難解すぎるように見えるため、長い識別子が好まれる場合があります。
• 長い識別子は見た目が乱雑になるので好まれない可能性がある

一部のプログラマーが短い識別子を好むのは、長い識別子よりも入力や考案が簡単だからなのか、あるいは多くの場合、長い識別子は単に目に見えるコードを乱雑にするだけで、認識される追加の利点がないからなのかは、未解決の研究課題です。

プログラミングの簡潔さは、次のような理由から生じます。

• 初期のリンカーでは、メモリを節約するために変数名を 6 文字に制限する必要がありました。その後の「進歩」により、人間が理解しやすいように長い変数名を使用できるようになりましたが、最初の数文字だけが重要になりました。TRS-80 Level 2 Basic などの一部のBASICバージョンでは、長い名前が許可されていましたが、最初の 2 文字だけが重要でした。この機能により、たとえば「VALUE」と「VAT」などの名前が使用され、区別されることを意図していた場合、デバッグが困難な誤った動作が発生する可能性がありました。
• オートコンプリート機能のない初期のソースコードエディタ
• 行の長さが制限されている初期の低解像度モニター（例：80文字のみ）
• コンピュータサイエンスの多くは数学に由来しており、変数名は伝統的に1文字のみである。

一部の命名規則では、文字の大文字と小文字のどちらで表示できるかを制限しています。その他の規則では、大文字と小文字を制限しませんが、大文字と小文字に基づいて明確に定義された解釈が付けられます。一部の命名規則では、アルファベット、数字、英数字のいずれの文字を使用できるのか、また使用できる場合はどのような順序で使用できるのかが指定されています。

一般的な推奨事項は、「意味のある識別子を使用する」ことです。1 つの単語は、複数の単語ほど意味がなかったり、具体的ではなかったりする場合があります。そのため、一部の命名規則では、複数の単語を含む「複合」識別子の扱いに関するルールが指定されています。

ほとんどのプログラミング言語では識別子に空白文字を使用できないため、各単語を区切る方法が必要です（後続の読者がどの文字がどの単語に属しているかを解釈しやすくするため）。歴史的には、FORTRAN（1955）やALGOL（1958）などの初期の言語では、コンテキストによって識別子の終わりを決定し、識別子内にスペースを使用できました。これは、トークン化の難しさのため、後の言語では廃止されました。単語を連結するだけで名前を書くことは可能であり、mypackageJavaパッケージ名のように時々使用されますが、^[4]長い用語では可読性が低下するため、通常は何らかの形式の区切りが使用されます。

1 つの方法は、英数字以外の文字を使用して個別の単語を区切ることです。この目的でよく使用される 2 つの文字は、ハイフン("-") とアンダースコア("_") です。たとえば、2 つの単語の名前 " " は、" " または " "と表されます。 two wordstwo-wordstwo_words

ハイフンは、COBOL (1959)、Forth (1970)、Lisp (1958) を書くほぼすべてのプログラマーによって使用されています。また、Unixのコマンドやパッケージでも一般的であり、CSSでも使用されています。^[5]この規則には標準的な名前はありませんが、lisp-caseまたはCOBOL-CASE ( Pascal caseと比較してください)、kebab-case、brochette-case、またはその他の変形と呼ばれることがあります。^{[6] [7] [8] [9]}これらのうち、kebab-case は少なくとも2012年にまで遡り、^[10]それ以来ある程度普及しています。^{[11] [12]}

対照的に、FORTRAN/ALGOL 系の言語、特にCおよびPascal系の言語では、減算 中置演算子にハイフンを使用し、その周囲にスペースを必要としなかったため (自由形式言語のように)、識別子での使用はできませんでした。

代替案としては、アンダースコアを使用する方法があります。これは C ファミリ (Python を含む) では一般的で、小文字の単語は、たとえばThe C Programming Language (1978) に見られ、スネークケースまたはスネイルケースとして知られるようになりました。UPPER_CASE のように大文字のアンダースコアは、 C プリプロセッサマクロ (MACRO_CASE と呼ばれる) や、bashの BASH_VERSION などの Unix の環境変数でよく使用されます。これは、ユーモアをこめて SCREAMING_SNAKE_CASE (または SCREAMING_SNAIL_CASE) と呼ばれることもあります。

もう 1 つの方法は、単語の境界を「camelCase」、「 PascalCase 」、その他さまざまな名前で呼ばれる中央大文字化を使用して示すことです。これにより、それぞれ「 」が「 」または「 」two wordsとして表示されます。この規則は、Pascal、Java、C#、およびVisual Basicで一般的に使用されます。識別子内の頭文字の扱い ( の「XML」および「HTTP」など) はさまざまです。入力、可読性、およびセグメント化を容易にするために小文字にする (例 ) ことを規定しているものもあれば、正確さのために大文字のままにする (例) ものもあります。 twoWordsTwoWordsXMLHttpRequestXmlHttpRequestXMLHTTPRequest

一部の命名規則は、特定のプロジェクトまたは問題領域の要件を超えたルールまたは要件を表し、代わりにソフトウェア アーキテクチャ、基礎となるプログラミング言語、またはその他の種類のプロジェクト間方法論によって定義された、より包括的な一連の原則を反映します。

おそらく最もよく知られているのはハンガリー記法で、変数の目的（「Apps Hungarian」）または型（「Systems Hungarian」）のいずれかを変数名にエンコードします。^[17]たとえば、変数szNameの接頭辞「sz」は、変数がヌル終端文字列であることを示します。

非常に短い (8 文字以下) 場合に使用されるスタイルは、LCCIIL01 です。ここで、LC はアプリケーション (信用状)、C は COBOL、IIL は特定のプロセス サブセット、01 はシーケンス番号です。

この種の規則は、 JCLに依存するメインフレームで現在でも積極的に使用されており、8.3 (ピリオド区切りの 8 文字までで、その後に 3 文字のファイル タイプが続く) MS-DOS スタイルでも見られます。

IBM の「OF 言語」は、IMS (情報管理システム) マニュアルに記載されています。

これは、「顧客アカウント番号」を示す「CUST-ACT-NO」などの名前で構成される PRIME-MODIFIER-CLASS 単語体系の詳細を示しています。

PRIME ワードは、システムにとって重要な「エンティティ」を示すためのものでした。

修飾語は、追加の洗練、修飾、および読みやすさのために使用されました。

理想的には、CLASS ワードは特定のアプリケーションに関連するデータ タイプの非常に短いリストになります。一般的な CLASS ワードは、NO (数値)、ID (識別子)、TXT (テキスト)、AMT (金額)、QTY (数量)、FL (フラグ)、CD (コード)、W (作業) などです。実際には、使用可能な CLASS ワードは 24 個未満の用語のリストになります。

CLASS 単語は通常右側 (接尾辞) に配置され、ハンガリー記法の接頭辞とほぼ同じ目的を果たします。

CLASS ワードの目的は、一貫性に加えて、特定のデータ フィールドのデータ型をプログラマーに指定することでした。BOOLEAN (2 つの値のみ) フィールドが受け入れられる前は、FL (フラグ) は、2 つの値のみを持つフィールドを示していました。

Adobe のコーディング規則とベストプラクティスでは、ActionScriptの命名標準がECMAScriptの命名標準とほぼ一致することが示されています。^{[引用が必要]}識別子のスタイルはJavaのスタイルに似ています。

Adaでは、識別子として推奨される唯一のスタイルはですMixed_Case_With_Underscores。^[18]

APL方言では、単語の間にデルタ (Δ) が使用されます (例: PERFΔSQUARE) (古い APL バージョンでは小文字は伝統的に存在しませんでした)。名前に下線付きの文字が使用されている場合は、代わりにデルタ アンダーバー (⍙) が使用されます。

CおよびC++では、キーワードと標準ライブラリの識別子はほとんどが小文字です。C 標準ライブラリでは、省略形の名前が最も一般的です (例:isalnum文字が英数字かどうかをテストする関数)。一方、C++ 標準ライブラリでは、単語の区切りとしてアンダースコアがよく使用されます (例: )。マクロout_of_rangeを表す識別子は、慣例により、大文字とアンダースコアのみを使用して記述されます (これは、多くのプログラミング言語で定数にすべて大文字の識別子を使用する慣例に関連しています)。 2 つのアンダースコアを含む名前、またはアンダースコアと大文字で始まる名前は、実装用に予約されており (コンパイラ、標準ライブラリ)、使用しないでください (例:または )。^{[19] [20]}これは表面的にはストロッピングに似ていますが、意味が異なります。アンダースコアは、引用符文字 (ストロッピング など) ではなく、識別子の値の一部です。 の値は(予約済み) であり、 (別の名前空間内) では ありません。__reserved_Reserved__foo__foofoo

C#の命名規則は、一般的にMicrosoftがすべての.NET言語に対して公開したガイドライン^[21]に従います（以下の.NETセクションを参照）が、C#コンパイラによって強制される規則はありません。

Microsoft のガイドラインでは、PascalCaseとのみを排他的に使用camelCaseし、後者はメソッド パラメータ名とメソッド ローカル変数名 (メソッド ローカルconst値を含む) にのみ使用することを推奨しています。識別子の先頭に 2 文字の頭字語がある場合は、PascalCase の特別な例外が適用されます。この場合、両方の文字が大文字になります (例: )。IOStream長い頭字語の場合はこの限りではありません (例: XmlStream)。ガイドラインではさらに、 に付ける名前の前に大文字の を付けるinterfaceことを推奨しています(例: ) 。 PascalCaseIIEnumerable

フィールドの命名に関する Microsoft のガイドラインはstatic、、、publicおよびprotectedフィールドに固有のものです。それ以外のフィールドstaticや、他のアクセシビリティ レベル (やなどinternal)を持つフィールドはprivate、明示的にガイドラインの対象外です。^[22]最も一般的な方法は、(でも でもない)PascalCaseフィールドを除くすべてのフィールドの名前に を使用することです。これらのフィールドには、 の前に 1 つのアンダースコアが付いた名前が付けられます。たとえば、 です。 privateconststaticcamelCase_totalCount

@識別子名には、意味を変えることなく、アットマーク記号 ( ) を接頭辞として付けることができます。つまり、 とfactorはどちらも@factor同じオブジェクトを参照します。慣例により、この接頭辞は、識別子が予約語 ( や などfor)でwhile、接頭辞なしでは識別子として使用できないか、コンテキスト キーワード ( や などfrom)である場合にのみ使用されますwhere。この場合、接頭辞は厳密には必要ありません (少なくとも宣言時には必須ではありません。たとえば、宣言は有効ですが、通常は と表示され、後者が変数名であることを読者にすぐに示すこと dynamic dynamic;ができます)。dynamic @dynamic;

Flutter SDKで使用されているDart言語では、定数が lowerCamelCase で記述されることを除いて、Java の規則に似ています。 Dart では、アンダースコア ( ) で始まる非ローカル識別子はプライベートとして扱われるという構文規則が課せられています (言語には public または private アクセスの明示的なキーワードがないため)。 さらに、ソースファイル名は Java の「ソースファイルごとに 1 つの public クラス、名前は一致する必要がある」という規則に従わず、ファイル名には snake_case を使用します。^[23]_

Goでは、複数単語の名前を書くときはアンダースコアではなくMixedCapsorを使うのが慣例となってmixedCapsいる。構造体や関数を参照する場合、最初の文字は外部パッケージの可視性を指定する。最初の文字を大文字にするとそのコード部分がエクスポートされ、小文字にすると現在のスコープ内でのみ使用可能になる。^[24]

Javaでは、識別子の命名規則は、Sun Microsystems、^[25] Netscape、^[26] AmbySoft、^[27]などのさまざまなJavaコミュニティによって確立され、提案されています。 Sun Microsystemsによって設定された命名規則の例を以下に示します。ここで、「CamelCase」の名前は、スペースなしで結合された複数の単語で構成され、各単語の最初の単語を除く最初の文字が大文字になります。たとえば、「camelCase」です。

Java コンパイラはこれらのルールを強制しませんが、それに従わないと混乱や誤ったコードが生じる可能性があります。たとえば、widget.expand()と はWidget.expand()大きく異なる動作を意味します。はという名前のインスタンスのwidget.expand()メソッド の呼び出しを意味しますが、 はクラス の静的メソッド の呼び出しを意味します。 expand()widgetWidget.expand()expand()Widget

広く使用されている Java コーディング スタイルの 1 つでは、クラスUpperCamelCaseには を使用し、インスタンスとメソッドには を使用することが規定されています。^[25] この使用法を認識して、Eclipseなどの一部のIDEでは、CamelCase に基づくショートカットを実装しています。たとえば、Eclipse のコンテンツ アシスト機能では、CamelCase の単語の大文字を入力するだけで、一致するクラス名またはメソッド名が提案されます (たとえば、「NPE」と入力してコンテンツ アシストを有効にすると、 が提案されます)。 lowerCamelCaseNullPointerException

3 文字以上の頭文字は、大文字ではなく CamelCase になります (例:parseDbmXmlFromIPAddressではなくparseDBMXMLFromIPAddress)。境界を 2 文字以上で設定することもできます (例: parseDbmXmlFromIpAddress)。

組み込みのJavaScriptライブラリは、Javaと同じ命名規則を使用します。データ型とコンストラクタ関数は大文字のキャメルケース（RegExp、TypeError、）を使用し、メソッドは小文字のキャメルケース（ 、 、 ）を使用しますXMLHttpRequest。一貫性を保つために、ほとんどのJavaScript開発者はこれらの規則に従います。^[28] 参照：Douglas Crockfordの規則 DOMObjectgetElementByIdgetElementsByTagNameNScreateCDATASection

ほとんどのLisp方言では、識別子内の単語を区切るためにダッシュを使用するのが一般的です（ およびwith-open-file）make-hash-table。動的変数名は慣例的にアスタリスクで始まり、終わります：*map-walls*。定数名はプラス記号でマークされます：+map-size+。^{[29] [30]}

Microsoft .NETではUpperCamelCase、ほとんどの識別子に （パスカルケースとも呼ばれる）を推奨しています。 （パラメータと変数lowerCamelCaseには が推奨されます）は、.NET言語の共通規則です。^{[31] Microsoftはさらに、型プレフィックスヒント（}ハンガリアン記法とも呼ばれる）を使用しないことを推奨しています。 [ ^32]ハンガリアン記法を使用する代わりに、の代わりに基本クラスの名前で名前を終了することが推奨されています。^[33]LoginButtonBtnLogin

Objective-Cには、 Smalltalkにルーツを持つ共通のコーディング スタイルがあります。

クラス、プロトコル、カテゴリ、およびグローバル変数や関数などの Objective-C プログラムで使用される C 構造を含むトップレベルのエンティティは、、、または のように、名前空間を示す短い大文字のプレフィックスが付いた UpperCamelCase で表されますNSString。UIAppDelegate定数NSAppにCGRectMakeは、 のように、オプションで小文字の「k」をプレフィックスとして付けることができますkCFBooleanTrue。

オブジェクトのインスタンス変数は、 や のように、アンダースコアで始まる lowerCamelCase を使用し_delegateます_tableView。

メソッド名は、application:didFinishLaunchingWithOptions:、stringWithFormat:のように、引数を区切るコロンで区切られた複数の lowerCamelCase 部分を使用しますisRunning。

ワーチアン言語であるPascal、Modula-2、Oberonでは、プログラム、モジュール、定数、型、手続きにはor識別子がCapitalized一般的に使用され、数学定数、変数、仮パラメータ、関数にはor識別子が使用されます。 ^[34]一部の方言では識別子にアンダースコアとドル記号がサポートされていますが、スネークケースとマクロケースは、外部APIインターフェース内での使用に限定される可能性が高いです。^[35]UpperCamelCaselowercaselowerCamelCase

Perl はC の慣習に倣っています。ローカルスコープの変数とサブルーチン名は小文字で、中置アンダースコアが付きます。プライベートとして扱われるサブルーチンと変数には、先頭にアンダースコアが付きます。パッケージ変数はタイトルケースです。宣言された定数はすべて大文字です。パッケージ名はプラグマ (例: と) を除いてキャメルケースで、strictプラグマmroは小文字です。 ^{[36] [37]}

PHPの推奨事項はPSR-1（PHP標準勧告1）とPSR-12に記載されています。^[38] PSR-1によれば、クラス名はPascalCase、クラス定数はMACRO_CASE、関数名とメソッド名はcamelCaseにする必要があります。^[39]

PythonとRuby はどちらもUpperCamelCase、クラス名、CAPITALIZED_WITH_UNDERSCORES定数、snake_caseその他の名前に を推奨しています。

Python では、名前が「プライベート」であることを意図している場合、1 つまたは 2 つのアンダースコアが前に付けられます。プライベート変数は Python では慣例によってのみ強制されます。名前にアンダースコアを末尾に付けることで、Python キーワードとの競合を防ぐこともできます。二重アンダースコアを前に付けると、名前のマングリングに関するクラスの動作が変わります。二重アンダースコアを前に付けたり後ろに付けたりすること (Python では「dunder」(「double under」) メソッドと呼ばれます) は、Python オブジェクトで特別な動作を実現する「マジック ネーム」用に予約されています。^[40]

Rには公式のスタイルガイドはありませんが、Rの第一人者Hadley Wickhamによるtidyverseスタイルガイドがほとんどのユーザーにとっての標準となっています。^[41] このガイドでは、ファイル名に特殊文字を避け、変数名と関数名には数字、文字、アンダースコアのみを使用することを推奨しています（例：fit_models.R）。

RakuはPerlとほぼ同じ規則に従いますが、識別子内に中置ハイフン-またはアポストロフィ（または一重引用符）を使用できます（ただし、2つ連続して使用することはできません）。ただし、その後ろにアルファベット文字が続く必要があります。そのため、Rakuプログラマーは識別子にケバブケースを使用することがよくあります。たとえば、 およびは有効な識別子です。 ^[42]'fish-fooddon't-do-that

Rustでは、UpperCamelCase型エイリアスと構造体、特性、列挙型、列挙型バリアント名、SCREAMING_SNAKE_CASE定数または静的変数、snake_case変数、関数、構造体のメンバー名にを推奨しています。 ^[43]

Swift は、リリースごとに命名規則を変更してきました。ただし、Swift 3.0 のメジャー アップデートでは、lowerCamelCase変数と関数宣言全体の命名規則が安定しました。定数は通常、列挙型または定数パラメータによって定義され、これらも同じように記述されます。クラスおよびその他のオブジェクト型の宣言は ですUpperCamelCase。

Swift 3.0では、すべてのサードパーティAPIにわたってAPIの命名と宣言の規則を標準化するために、言語の命名ガイドラインが明確に定められました。 ^[44]

• カテゴリ:命名規則
• チェックスタイル
• コーディング規約
• 静的コード解析ツールの一覧
• 名前空間
• 命名規則
• Sigil（コンピュータプログラミング）
• 構文（プログラミング言語）

• coding-guidelines.com には、言語学と心理学を用いて識別子の命名問題の費用対効果分析を試みた PDF があります。