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

課題

命名規則の選択とその実施は、論争になりやすく、各人がどんな命名規則が最善かについて意見を持っていることが多い。
さらに、よく知られている命名規則を採用したとしても、全体に実施を徹底させることができなければ、一貫性がなくなり、混乱が生じる。
このような課題は、その命名規則が一貫しておらず、記憶しづらく、利点よりも欠点が多いような場合には、さらに悪化する。

ビジネス上の価値

ソフトウェアシステムやアプリケーションソフトウェアのエンドユーザーが識別子名の良し悪しを意識することはほとんどない。ソースコード上の識別子名は、通常ユーザーインターフェイスに表出することはないからである。しかし、システムを引継いでいく開発者やアナリストにとっては、識別子が適切に選定されていることで、システムが何をしているかを理解したり、さらには新たなビジネス所要に応じてソースコードをどのように修正・拡張すればよいかを判断したりすることが極めて容易となる。
例えば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・ライブラリのほうが、機能を類推しやすくなる（インターフェイス自体がマニュアルとなる）ため、生産性の向上にもつながる。

典型的要素

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

大文字/小文字と数字

命名規則によっては、大文字と小文字の使い方を制限しているものもある。また、大文字も小文字も使えるが、それらに意味を与える場合もある。アルファベット、数字、両方を混合した英数字の使い方を指定した命名規則もある。プログラミング言語によっては大文字と小文字を区別しないものもある。

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

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

メタデータと命名規則

命名規則によっては、特定のプロジェクトや問題領域に必要とされる規則や必要条件というだけでなく、ソフトウェアアーキテクチャによって定義される原則、根底にあるプログラミング言語やプロジェクト横断的な方法論などを表す大きな枠組みを提供する。
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）が二値だけをとるフィールドを示していた。

Smalltalk

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

Java

Javaでは、言語仕様および標準ライブラリの設計時点から、クラスやメソッド、定数や変数などの命名における大文字/小文字の使い分けといった規則が決められている。例えば、クラス名は大文字で始める (upper camel)、メソッド名や変数名は小文字で始める (lower camel)、また定数名はすべて大文字でアンダースコア区切りとする、などである。
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ではアンダースコア1文字の識別子_は予約済みのキーワード（予約語）となったため、ユーザーコードで識別子として使用することはできなくなった。

BASIC、Visual Basic、VB.NET

BASICは、C言語と違って大文字/小文字の区別をしない言語である。処理系は大文字/小文字の違いを無視してシンボルの識別をしている。これはVisual Basic (VBAを含む) およびVisual Basic .NETにおいても受け継がれている。したがって、例えば form.show, Form.Show, FORM.SHOW はすべて同じ意味になる。ただし、識別子名は人間にとって読みやすいほうが好ましいため、VB/VB.NETでは通例シンボルの宣言時に大文字/小文字を使い分け、シンボルを利用する際も宣言に応じて区別する命名規則が採用される（IDEによるコード補完や自動フォーマットの際も宣言名が利用される）。型名やメソッド名、プロパティ名は大文字で始めるアッパーキャメルが採用されている。
かつてVB/VBAでは、GUI要素（コントロール）などの変数名に、略語の接頭辞（ハンガリアン記法）を使う命名規則が推奨されていたが、VB.NET (Windows FormsおよびWPFなど) ではそのようなガイドラインは存在せず、ハンガリアン記法は非推奨となっている。

C#

C#言語および.NET Frameworkは、もともとDelphiの文法や言語機能およびVCLがベースになっていることもあり、Microsoftによる標準的な命名規約も（C/C++よりはむしろ）Delphiに似たものを踏襲している。
C#はC/C++やJava同様に大文字/小文字を区別するが、VB.NETを始めとする他の言語との相互運用性の観点から、大文字/小文字の違いしかないシンボル群をAPI外部に公開することは避けるべきとされている。