命名規則（めいめいきそく、英: "Naming conventions"）とは、プログラミングを行う際に識別子の名称となる文字列を決定するためのルールを定めたもの。ネーミング規則、ネーミング規約、命名規約とも呼ぶ。通常は、ソースコードの可読性や視認性の向上、プログラミング効率の改善などを目的としている。命名規則は、プログラミング言語の仕様、メモリサイズ等のハードウェア的な制約、エディタや IDE の機能などに影響を受けていることがある。命名規則を決めた場合の潜在的利点としては、以下のものが挙げられる。命名規則の選択とその実施は、論争になりやすく、各人がどんな命名規則が最善かについて意見を持っていることが多い。さらに、よく知られている命名規則を採用したとしても、全体に実施を徹底させることができなければ、一貫性がなくなり、混乱が生じる。このような課題は、その命名規則が一貫しておらず、記憶しづらく、利点よりも欠点が多いような場合には、さらに悪化する。エンドユーザーが識別子の良否を意識することはほとんどないが、システムを引継いでゆくアナリストや開発者にとっては、識別子が適切に選定されていることで、システムが何をしているかを理解したり、さらには新たなビジネス所要に応じてソースコードをどのように修正・拡張すればよいかを判断することが極めて容易となる。例えば、というコードは文法的に間違っているわけではないが、その意図・意味は見当もつかない。これに対して、というコードでは、少なくともアプリケーションの基本的な前後関係を理解している人には意味・意図がよくわかる（weekly_pay = 週給、hours_worked = 勤務時間、pay_rate = 時給）。また、各種APIや外部で開発されたサードパーティ製のライブラリを利用する場合も、適切な識別子命名規則に基づいて整理されたAPI・ライブラリのほうが、機能を類推しやすくなる（インターフェイス自体がマニュアルとなる）ため、生産性の向上にもつながる。命名規則は実際には、開発する対象や環境に依存する。しかし、多くの命名規則に共通に見られる要素がいくつか存在する。命名規則の最も基本的な規則は識別子の長さに関するものである（長さの限度および識別子に使える文字の種類）。数値を挙げて上限を設定する場合もあれば、もっと緩やかなガイドラインを設定する場合もある。識別子長の規則は議論の的になりやすく、学術的な議論にもなっている。考慮すべき点:これらの要素がどのように絡み合ってプログラマの好みが形成されるのかは明らかではなく、今後の研究が待たれる。初期のリンケージエディタには、メモリ使用量を抑えるために変数名などを6文字以内に制限していたものがあり、そのために古いプログラムで識別子が短く制限されていたという事実もある。命名規則によっては、大文字と小文字の使い方を制限しているものもある。また、大文字も小文字も使えるが、それらに意味を与える場合もある。アルファベット、数字、両方を混合した英数字の使い方を指定した命名規則もある。一般に「意味のある識別子」が推奨される。1つの単語では意味がわかりにくい場合もあり、複数の単語を識別子に使用することになる。結果として、命名規則には、複数の単語を連結する場合の方法が指定されることになる。多くのプログラミング言語は識別子内に空白を許さない。そのため、空白以外で単語の区切りを示す方法が必要となる（区切りを示さないと、可読性が低くなる）。命名規則によっては、特定のプロジェクトや問題領域に必要とされる規則や必要条件というだけでなく、ソフトウェアアーキテクチャによって定義される原則、根底にあるプログラミング言語やプロジェクト横断的な方法論などを表す大きな枠組みを提供する。最もよく知られている命名規則としてハンガリアン記法がある。これには、「目的」を名前に含める方式（アプリケーションハンガリアン）と、「データ型」を名前に含める（システムハンガリアン）に分けられる。非常に短い（8文字以下）長さで識別子を形成する場合、桁位置ごとに意味を持たせることがある。例えば、LCCIIL01 という名前で、先頭の LC は「信用状（letter of credit）、次の C は COBOL、IIL は 特定のプロセスサブセットを表し、01 がシーケンス番号となっている。このような規則はメインフレームでのJCLなどで今でも使われている。また、MS-DOSでのファイル名（8文字＋拡張子3文字という制限がある）でも見られる。初期の命名規則として、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）が二値だけをとるフィールドを示していた。C と C++ では、キーワードや標準Cライブラリの識別子の多くは小文字である。これは、標準ライブラリーと使用者が定義した関数や変数を区別するためであり使用者が定義する場合は大文字を含む名前が推奨されている。また、マクロで定義される識別子は、"マクロ以外の識別子との衝突を避けるため"慣習として大文字で書かれることが多い（これは、多くの言語で定数が大文字で書かれることと関連している）。また、アンダースコア2個、あるいはアンダースコアと大文字1個ずつで始まる名前は、実装上（コンパイラや標準ライブラリに）予約されているため、ユーザーは使えない（例えば、codice_1 や codice_2）。Smalltalkでは、大域変数(クラス名も含む(クラスも大域変数であるため))は大文字からはじまるキャメルケース、局所変数、メンバーとなる変数は小文字からはじまるキャメルケースを使用する。これは、言語仕様でもきまっており、存在しない大文字ではじまる変数を参照するコードを書いても翻訳時にエラーとはならないが、存在しない小文字の変数を参照するコードを書いていると翻訳時にエラーとなる。また、メソッドが存在するセレクター(関数名のようなもの)は、小文字ではじまるキャメルケースを使い、メソッドが存在しないセレクターには大文字ではじまるキャメルケースを用いることが慣習になっている。これは、名前空間の解決等でメソッドが存在しないセレクターを使おうとした時、基底クラス等にメソッドが存在するとメソッドを呼んでしまうためである。後発のJavaなどはこの規則を強く継いでいる。ただし、Smalltalkにはプリプロセッサは存在しないため、全部大文字の識別子を使う慣習は存在しない。Javaでは、言語設計時点からクラスや変数での大文字の使い方が決められている。従って、Javaプログラマにとっては、codice_3 と codice_4 では全く違う意味になる。これはコンパイラがそのような制限をかけているわけではないし、codice_5 クラスについてユーザーが知らなくても関係ない。BASICは本来、C言語と違って大文字/小文字の区別をしていない言語である。IDEは場当たり的に変数の識別をしている。そのため、Visual Basic の命名規則は人間によって読みやすいように設定される傾向があり、識別子自身に関する情報をもたせようとしない。従って、C言語で codice_6 となっている識別子は Visual Basic では codice_7 となる傾向があり、codice_3 と codice_4 は同じ意味になる。Delphi言語は、VB系の言語と同様、大文字/小文字の区別を行なわないが、下記の命名規約が推奨されている。なお、Delphiの文法や言語機能を一部導入しているC#言語および.NET Frameworkは、Microsoftによる標準的な命名規約も（C/C++よりはむしろ）Delphiに似たものを踏襲している。

出典:wikipedia