ハンガリー記法

ハンガリアン記法は、コンピュータプログラミングにおける識別子の命名規則であり、変数または関数の名前がその意図または種類、または一部の方言ではその型を示します。元のハンガリアン記法では、命名規則で意図または種類のみを使用し、Microsoft Officeアプリケーションの開発で Microsoft Apps 部門で人気になったため、 Apps ハンガリアンと呼ばれることもあります。Microsoft Windows部門が命名規則を採用したとき、実際のデータ型に基づいて命名規則が採用され、この規則はWindows APIを通じて広く普及しました。これは、システム ハンガリアン記法と呼ばれることもあります。

ハンガリアン記法は言語に依存しないように設計されており、BCPLプログラミング言語で初めて広く使用されました。BCPL にはマシンワード以外のデータ型がないため、言語自体にはプログラマが変数の型を覚えるのに役立つものがありません。ハンガリアン記法は、各変数のデータ型に関する明示的な知識をプログラマに提供することで、この問題を解決することを目的としています。

ハンガリー記法では、変数名は、その変数の型または目的を表す小文字のグループで始まり、その後にプログラマーが選択した名前が続きます。この最後の部分は、指定された名前として区別されることがあります。指定された名前の最初の文字は、型インジケータと区別するために大文字にすることができます ( CamelCaseも参照)。それ以外の場合、この文字の大文字/小文字はスコープを示します。

ハンガリー記法の原型は、1972年から1981年頃にゼロックスPARCで働き、後にマイクロソフトのチーフアーキテクトとなったプログラマー、チャールズ・シモニによって考案された。この記法の名前はシモニの出身国にちなんで付けられているが、アンディ・ヘルツフェルドによれば、この記法によってプログラムが「不可解な外国語で書かれたように見える」ためでもあるという。^[2]ハンガリー人の名前は、他のほとんどのヨーロッパ人の名前と比べて「逆」になっている。つまり、姓が名の前に来る。たとえば、ハンガリー語の英語化された名前「チャールズ・シモニ」は、もともと「シモニ・カーロイ」だった。同様に、ハンガリー記法では型名が「名」の前に来る。同様のSmalltalkの「型を最後にする」命名スタイル（例：aPointとlastPoint）は、シモニが在職していた当時、ゼロックスPARCで一般的だった。^[要出典]

Simonyi の表記法に関する論文では、格納されている情報の「タイプ」を示すために使用される接頭辞について言及されています。^{[3] [4]}彼の提案は、主に、格納されているものの意味情報 (つまり、変数の目的) に基づいて識別子名を装飾することに関するものでした。Simonyi の表記法は、Microsoft のアプリケーション部門で使用されていたため、Apps Hungarian と呼ばれるようになりました。Systems Hungarian は、後にMicrosoft Windows開発チームで開発されました。Apps Hungarian は、Systems Hungarian として知られるようになったものと完全には異なります。Simonyi が提案した接頭辞の中には、意味情報がほとんどまたはまったく含まれていないものもあります (例については以下を参照)。^[4]

システム表記とアプリ表記の違いは、プレフィックスの目的にあります。

Systems Hungarian 表記法では、プレフィックスは変数の実際のデータ型をエンコードします。例:

• lAccountNum : 変数は長整数です( "l");
• arru8NumberList : 変数は符号なし8ビット整数の配列です（"arru8"）;
• bReadLine(bPort,&arru8NumberList) : バイト値の戻りコードを持つ関数。
• strName"str": 変数は名前を含む 文字列 ( ) を表しますが、その文字列がどのように実装されるかは指定しません。

アプリのハンガリアン記法は、物理データ型ではなく論理データ型をエンコードするように努めています。このようにして、変数の目的やそれが表すものについてのヒントが与えられます。

• rwPosition : 変数は行を表します( "rw");
• usName: 変数は安全でない文字列( ) を表し"us"、使用する前に「サニタイズ」する必要があります (たとえば、生のユーザー入力を使用することで発生する可能性のある攻撃の例については、コード インジェクションとクロスサイト スクリプティングを参照してください)
• szName : 変数はゼロで終了する文字列 ( ) です。これは、 Simonyi"sz"が最初に提案したプレフィックスの 1 つです。

Simonyi が提案したプレフィックスのほとんどは、本質的に意味論的ですが、すべてではありません。現代の視点から見ると、一部のプレフィックスは、sz文字列などの物理的なデータ型を表しているように見えます。しかし、そのようなプレフィックスは依然として意味論的であり、Simonyi は、現代の言語が当然としている一部のデータ型を型システムが区別できない言語用のハンガリー記法を意図していました。

以下は原論文からの例である: ^[3]

• pXは別の型Xへのポインタです。これには意味情報がほとんど含まれていません。
• dは、2 つの値の差を意味する接頭辞です。たとえば、dY はグラフの Y 軸に沿った距離を表す場合がありますが、単にyと呼ばれる変数は絶対位置を表す場合があります。これは完全に意味的な性質です。
• szは、ヌルまたはゼロで終了する文字列です。C では、 char*型の変数が単一の文字、文字の配列、またはゼロで終了する文字列へのポインターであるかどうかが明確ではないため、これには何らかの意味情報が含まれます。
• w単語である変数を示します。これには本質的に意味情報がまったく含まれておらず、おそらく Systems Hungarian と見なされます。
• bバイトをマークします。 w とは対照的に、バイトには意味情報が含まれている可能性があります。これは、C ではバイトサイズのデータ​​型はcharのみであるため、数値を保持するために使用されることがあるためです。このプレフィックスにより、変数が文字として扱うべき値を保持しているのか、数値として扱うべき値を保持しているのかのあいまいさが解消される可能性があります。

この表記法ではニーモニックとして常に先頭の小文字を使用しますが、ニーモニック自体は規定されていません。広く使用されている規則がいくつかあります (以下の例を参照)。ただし、特定のコード本体内で一貫している限り、任意の文字セットを使用できます。

Apps ハンガリー記法を使用するコードでは、型のみに基づいて定義される変数を記述するときに、Systems ハンガリー記法が含まれる場合があります。

一部のプログラミング言語では、現在シギルと呼ばれる同様の表記法が言語に組み込まれており、コンパイラによって強制されます。たとえば、BASICの一部の形式では、は文字列name$を指定し、 は整数を指定します。ハンガリー記法とシギルの主な違いは、シギルは言語内の変数の型を宣言するのに対し、ハンガリー記法は純粋に命名スキームであり、プログラム テキストのマシン解釈には影響を及ぼさないことです。 count%

• bBusy :ブール
• chInitial :文字
• cApples : アイテム数
• dwLightYears : ダブルワード(システム)
• fBusy :フラグ(またはfloat )
• nSize :整数(システム) または count (アプリ)
• iSize :整数(システム) またはインデックス (アプリ)
• fpPrice :浮動小数点
• decPrice : 小数
• dbPi :ダブル（システム）
• pFoo :ポインタ
• rgStudents : 配列または範囲
• szLastName : ゼロ終端文字列
• u16Identifier : 符号なし16ビット整数（システム）
• u32Identifier : 符号なし32ビット整数（システム）
• stTime : 時計の時間構造
• fnFunction : 関数名

実際のデータ型ではないポインタと配列のニーモニックの後には、通常、データ要素自体の型が続きます。

• pszOwner : ゼロ終端文字列へのポインタ
• rgfpBalances:浮動小数点値 の配列
• aulColors : unsigned long の配列 (システム)

ハンガリアン記法は、あらゆるプログラミング言語や環境に適用できますが、MicrosoftによってC 言語、特にMicrosoft Windowsで使用するために広く採用され、その使用は主にその領域に限定されています。特に、ハンガリアン記法の使用は、Windows APIプログラミングに関する最初の (そして多くの読者にとって決定版の) 書籍であるCharles Petzoldの「Programming Windows」によって広く普及しました。したがって、よく見られるハンガリアン記法の構成要素の多くは、Windows に固有のものです。

• C で Windows プログラミングを学んだプログラマーにとって、おそらく最も記憶に残る例は、WindowProcwParam () 関数の(ワード サイズ パラメーター) とlParam(長整数パラメーター)でしょう。
• hwndFoo : ウィンドウのハンドル
• lpszBar : ゼロ終端文字列への長いポインタ

C++では、変数のスコープを含めるために表記法が拡張されることがあり、オプションでアンダースコアで区切られる。 ^{[5] [6]}この拡張は、ハンガリー語の型指定なしで使用されることもよくある。

• g_nWheels : グローバル名前空間のメンバー、整数
• m_nWheels : 構造体/クラスのメンバー、整数
• m_wheels, _wheels : 構造体/クラスのメンバー
• s_wheels : クラスの静的メンバー
• c_wheels : 関数の静的メンバー

jQueryを使用するJavaScriptコードでは、変数がjQueryオブジェクト（単純なDOMオブジェクトや他の値ではなく）を保持していることを示すためにプレフィックスがよく使用されます。^[7]$

(これらの一部は Systems Hungarian にのみ適用されます。)

支持者は、ハンガリー記法の利点として以下を挙げている。^[3]

• シンボルの種類は名前から確認できます。これは、コードレビューやプリントアウトなど、統合開発環境の外部でコードを確認する場合や、関数など、シンボル宣言が使用ポイントとは別のファイルにある場合に便利です。
• 動的型付けを使用する言語や型付けのない言語では、型を参照する装飾は冗長ではなくなります。このような言語では、変数は通常、特定のタイプのデータを保持するものとして宣言されないため、変数に対してどのような操作を実行できるかについての唯一の手がかりは、変数の命名スキーム、ドキュメント、コメントなど、プログラマーによって提供されるヒントです。前述のように、ハンガリアン記法はこのような言語で拡張されました ( BCPL )。
• 変数名のフォーマットにより、コード リファクタリングのいくつかの側面が簡素化される可能性があります(ただし、他の側面ではエラーが発生しやすくなります)。
• コード ブロック内で、同様のセマンティクスを持つ複数の変数を使用できます: dwWidth、iWidth、fWidth、dWidth。
• 変数名は、その型さえわかれば簡単に覚えられます。
• 変数名の一貫性が向上します。
• 不適切な型キャストや互換性のない型を使用した操作は、コードを読みながら簡単に検出できます。
• 多くのグローバル オブジェクト (VB/Delphi フォーム) を含む複雑なプログラムでは、基本的なプレフィックス表記を使用すると、エディター内でコンポーネントを見つける作業が簡単になります。たとえば、文字列を検索すると、btnすべての Button オブジェクトが見つかる場合があります。
• ハンガリー記法をより狭い範囲、たとえばメンバー変数にのみ適用することで、名前の衝突を回避するのに役立ちます。
• データ型、型変換、割り当て、切り捨てなどの場合には、印刷されたコードの方が読者にとって明確になります。

ハンガリー記法に対する反論のほとんどは、システムのハンガリー記法に対するものであり、アプリのハンガリー記法に対するものではありません^{[引用が必要]}。潜在的な問題としては、次のようなものがあります。

• コンパイラによって型チェックが行われる場合、ハンガリアン記法は冗長です。Pascalなどの厳密な型チェックを提供する言語のコンパイラは、変数の使用がその型と一致することを自動的に保証します。目視によるチェックは冗長であり、人為的エラーの影響を受けます。
• 最新の統合開発環境のほとんどは、変数の型をオンデマンドで表示し、互換性のない型を使用する操作に自動的にフラグを立てるため、この表記法はほとんど時代遅れになっています。
• ハンガリアン記法は、次のように複数のプロパティを表すために使用される場合、混乱を招きます a_crszkvc30LastNameCol。定数 参照 引数は、テーブルの主キーの一部であるvarchar (30)型のデータベース列の内容を保持します。LastName
• コードを変更または移植すると、不整合が発生する可能性があります。変数の型が変更されると、変数名の装飾が新しい型と一致しなくなるか、変数名を変更する必要があります。特によく知られている例は、標準の WPARAM 型と、多くの Windows システム関数宣言に含まれる wParam仮パラメータです。「w」は「word」の略で、「word」はプラットフォームのハードウェア アーキテクチャのネイティブ ワード サイズです。これは、もともと 16 ビット ワード アーキテクチャでは 16 ビット型でしたが、オペレーティング システムの後のバージョンでは、元の名前を保持したまま、32 ビット ワード アーキテクチャでは 32 ビットに、64 ビット ワード アーキテクチャでは 64 ビット型に変更されました (実際の基になる型は UINT_PTR、つまり、ポインターを保持できる大きさの符号なし整数です)。セマンティックインピーダンス、つまりプラットフォーム間でのプログラマーの混乱と不一致は、異なる環境では「w」が 2 バイトの 16 ビット ワードを表すという仮定に基づいています。
• ほとんどの場合、変数の用途を知ることは、その型を知ることを意味します。さらに、変数の用途が不明な場合は、その型から推測することはできません。
• ハンガリアン記法では、変数名の補完をサポートするコード エディターを使用する利点が少なくなります。これは、プログラマーが最初に型指定子を入力する必要があり、他の命名スキームを使用する場合よりも他の変数と衝突する可能性が高くなるためです。
• 型とスコープのプレフィックスによって変数の目的がわかりにくくなり、コードの可読性が低下します。^[8]
• 追加の型情報は、より説明的な名前を十分に置き換えることはできません。たとえば、sDatabase ではそれが何であるかがわかりません。databaseName の方が説明的な名前になるかもしれません。
• 名前が十分に説明的であれば、追加の型情報は冗長になる可能性があります。たとえば、firstName はおそらく文字列です。そのため、sFirstName という名前を付けると、コードが乱雑になるだけです。
• 名前を覚えるのが難しくなります。
• 異なるセマンティクスを持つ複数の変数を、類似した名前を持つコード ブロック内で使用できます ( dwTmp、iTmp、fTmp、dTmp )。

• ロバート・セシル・マーティン（ハンガリー記法および他のすべての形式のエンコードに反対）：

  ...今日では、HN やその他の形式の型エンコーディングは単なる障害です。変数、関数、メンバー、クラスの名前や型を変更するのが難しくなります。コードが読みにくくなります。また、エンコーディング システムが読者を誤解させる可能性も生じます。^[9]

• Linus Torvalds (Systems Hungarian に対して):

  関数の型を名前にエンコードする（いわゆるハンガリアン記法）のは頭が悪いです。コンパイラはとにかく型を知っていて、それをチェックできるので、プログラマを混乱させるだけです。^[10]

• スティーブ・マッコーネル（ハンガリー語版アプリ担当）：

  ハンガリー語の命名規則はもはや広く使われていませんが、簡潔で正確な略語を標準化するという基本的な考え方は今でも価値があります。標準化されたプレフィックスを使用すると、コンパイラが必ずしもチェックできない抽象データ型を使用している場合でも、型を正確にチェックできます。^[11]

• Bjarne Stroustrup (C++ 向け Systems Hungarian に対して):

  いいえ、私は「ハンガリアン」を推奨しません。私は「ハンガリアン」（変数名に型の短縮版を埋め込む）を、型なし言語では役立つテクニックであると考えていますが、ジェネリックプログラミングとオブジェクト指向プログラミングをサポートする言語にはまったく適していません。どちらも、型と引数（言語またはランタイムサポートに既知）に基づいて操作を選択することを重視しています。この場合、「オブジェクトの型を名前に組み込む」ことは、抽象化を複雑にし、最小限に抑えるだけです。^[12]

• Joel Spolsky (ハンガリー語版アプリ担当):

  Simonyi の論文をよく読むと、彼が言おうとしていたのは、私が上の例で使ったのと同じ種類の命名規則で、 はus安全でない文字列を意味し、sは安全な文字列を意味すると決めていた。これらは両方とも 型であるstring。一方を他方に代入してもコンパイラは役に立たないし、Intellisense [インテリジェントなコード補完システム] も何も教えてくれない。しかし、これらは意味的に異なる。これらは異なる方法で解釈され、異なる方法で扱われる必要があり、一方を他方に代入する場合は何らかの変換関数を呼び出す必要がある。そうしないと、実行時バグが発生する。運が良ければの話だが。それでも、Apps Hungarian には、コード内のコロケーションを増やすという点で非常に大きな価値がある。これにより、コードの読みやすさ、書きやすさ、デバッグ、保守が容易になり、最も重要な点として、間違ったコードが間違って見えるようになる... (Systems Hungarian) は、Simonyi の意図と実践に対する微妙だが完全な誤解だった。^[4]

• Microsoftの設計ガイドライン^{[13]では、.NETクラスライブラリの要素の名前を選択する際にシステムハンガリアン記法を使用することを推奨していません。ただし、} Visual Basic 6以前のMicrosoft開発プラットフォームではシステムハンガリアン記法が一般的でした。これらの設計ガイドラインでは、関数内のローカル変数の命名規則については言及されていません。

• Leszynski 命名規則、データベース開発用のハンガリー語の変種
• キャメルケース、もう一つの広く普及している命名規則
• ポーランド記法、似た名前を持つ無関係な概念

• メタプログラミング: ソフトウェア生産方法 Charles Simonyi、1976 年 12 月 (博士論文)
• ハンガリー記法 - 今度は私の番です :) – Larry Osterman の WebLog
• ハンガリー記法 (MSDN)
• Doug Klunder の論文の HTML バージョン^{[永久リンク切れ‍ ]}
• RVBA 命名規則
• コーディング スタイル規則 (MSDN)