ハンガリアン記法（Hungarian Notation）は、ソフトウェア開発における変数名の命名規則として、かつて広く利用されてきた手法です。
特に、コードの可読性や変数の意味を明示的にする目的で、Windows APIや古いC++プロジェクトなどで活用されていました。
本記事では、ハンガリアン記法の種類・目的・利点・注意点を含めた詳細解説を通して、現在の開発現場におけるその意義や活用可能性を掘り下げていきます。
ハンガリアン記法とは？
命名に意味を持たせる記法
ハンガリアン記法とは、変数名の先頭にデータの種類・目的・形式などを表す接頭辞（prefix）を付けることで、変数の性質を一目で把握できるようにする命名規則です。
この命名規則を提唱したのは、Microsoftの元エンジニアであるチャールズ・シモニー（Charles Simonyi）で、彼がハンガリー出身であることからこの名前が付けられました。
ハンガリアン記法の2つの分類
アプリケーションハンガリアン（Apps Hungarian）
こちらは、変数の意味・用途を表現することを目的とした命名です。
データ型ではなく、ビジネス的な意味に基づいて接頭辞を付けるのが特徴です。
例：
このように記述することで、「異なる通貨を直接加算するのはおかしい」という文脈上のミスを変数名だけで回避しやすくなる利点があります。
主な用途：
-
金額、単位、条件などビジネスロジックが複雑なプロジェクト
-
チーム開発で意味の誤解を減らす目的
システムハンガリアン（Systems Hungarian）
こちらは、変数のデータ型（型情報）を示す接頭辞を使う形式です。
多くの場合、次のような接頭辞が使用されます。
注意点：
これはプログラミング言語の型チェックとは無関係で、あくまで開発者の理解を助けるための表記です。
たとえば iPrice という変数名だからといって、コンパイラが自動的にint型として扱うわけではありません。
IT分野での活用と評価
メリット
-
コードの可読性が向上
一目で変数の内容や型がわかるため、他人のコードを読みやすくなる。 -
自己文書化コードを実現
コメントを書かなくても、変数名から意味が伝わる。 -
チーム開発の効率化
命名ルールを統一することで、開発者間の認識ずれを防止。
デメリット・時代遅れとされる背景
-
IDEによる型補完が一般化
現代のエディター（VSCode、IntelliJなど）ではホバー表示や型推論機能が充実しており、型名を変数名に入れる必要性が薄れている。 -
冗長で読みづらくなることも
bIsUserLoggedInのように冗長な表記がコードの可読性を逆に落とすケースもある。 -
リファクタリングの手間
型が変わった場合に、変数名の接頭辞も変更する必要があり、保守性が低くなる。
モダン開発における位置づけ
推奨される場合
-
レガシーコードとの互換性を保つ必要がある場合
-
命名ルールを厳格に統一したい大規模プロジェクト
-
言語仕様上の型推論が弱い開発環境
非推奨または代替手段
-
強く型付けされた言語（Java, TypeScriptなど）では不要
-
CamelCaseやPascalCaseと併用したわかりやすい命名が推奨される
例（現代的な命名）：
まとめ
ハンガリアン記法は、変数の意味や型情報を命名で表現することで、コードの可読性と安全性を高める目的で生まれた命名ルールです。
ポイントの整理：
-
アプリケーションハンガリアン：意味を示す → 業務ロジックのミス回避に有効
-
システムハンガリアン：型を示す → 現代では一部言語・環境を除き、非推奨傾向
結論：
現代ではIDEの進化により必要性は薄れつつあるものの、目的に応じて適切に使い分けることで、依然として有用な命名スタイルとなり得ます。
特に、コードベースの長期保守性を重視する場合には、今なお価値のあるアプローチです。