命名規則のアンチパターン ハンガリアン記法
識別子の命名規則の 1 つであるハンガリアン記法の紹介をします。Microsoft が提供する Win32 API で利用されていたためかつては使われることが多かったですが、現在ではあまり推奨されていません。 ここではアンチパターンの 1 つとして紹介します。
ハンガリアン記法とは？
- 変数名やクラス名などの識別子に、ある規則に則った接頭辞 (prefix) や接尾辞 (suffix) を付ける命名則のことです
- それらによって使用方法、型、スコープに関する情報を付け加えます
- 例) 文字列なら先頭に
sを付ける - 例) ポインターなら先頭に
p,lpを付ける - 規約にも依りますが、型情報を接頭辞としてつけることが多いです
- 識別子を利用する側から、型など間違いがあることを視覚的に分かるようにすることを目的としていることが多いです
なぜダメなのか？
2022 年現在では、ハンガリアン記法を導入することはあまり推奨されていません。以下に、その理由を列挙します。
ソースコードの修正コストが上がる
- 識別子に型情報が入っているため、型の変更を行う際にその識別子を利用している全ての箇所の書き換えが必要になります
- 修正が追い付いていない場合、実際の型とハンガリアン記法で明記された型の間にズレが生じることになります
命名測がしっかりしていれば、そもそも不要であり、むしろ冗長
- 命名則がしっかりとしていれば、識別子の名前から型情報は類推可能なはずです
- ハンガリアン記法による接頭辞が無いと型が分からない場合は、命名規則を見直す必要があります
型に関する情報が容易に手に入る様になった
静的型付け言語でコードを記述し、開発環境として IDE (統合開発環境) を利用していれば、各変数の型が何であるかはツール上で簡単に確認することが出来ます。 多くのモダンなエディターでは、変数にマウスカーソルを当てれば、ツールチップで型に関する情報が表示されます。 そのため、変数名に型に関する情報を追加する意味はあまりありません。
そもそもハンガリアンを正確に覚えなければならない
- 最低でもプリミティブ型の数だけ接頭辞があることになります や ここ
- また、型を明記するという都合上、プリミティブ型の体系の異なる言語間での再利用は難しいです
場合によっては利用する場合も
環境によってはハンガリアン記法を利用する場合もあります。
- MFC や Win32 API では、ライブラリ側で利用されているため、故意に外すとそれはそれで一貫性を損なうと考える場合
- プログラミング言語の標準の命名規則にハンガリアン記法に該当する項目が含まれている場合
- C# の
interfaceの頭のIなど - 既存のプロジェクトなどのコーディング規約に既に盛り込まれている場合
ただし、特に考えもせずに利用して良いモノでは無いです。『goto 文も必要な場合がある』というのと同じく、一定の技術レベルがあり、必要性を判断できない場合には利用しない方が良いでしょう。
ハンガリアン記法もどき
ハンガリアン記法をハンガリアン記法だと認識して利用している場合にはまだ良いですが、そうとは気付かずに利用している場合もあるため注意が必要です。 明確にコーディング規約に明記されているわけでは無く、実装者の手癖でその様な命名を行っている場合です。 いくつか例を紹介します。
class 名に Class とつける
class 名の末尾に Class とつける行為は、事実上のハンガリアン記法です。 構造体の末尾に Struct とつける行為も同様です。 何らかの分類 (class) を取り扱う class であれば問題ないですが、そうでない場合には避けたほうが良いです。 少なくとも class であることを明示するために利用することは避けるべきです。
関数名に Function や Command を付ける
こちらも同様です。関数名には『○○ をする』と明記されているはずなので、そこに更に Function とつけるのは冗長です。 関数が関数であることは宣言した箇所でも、呼び出す箇所でも、文法上自明な場合が多いです。 ただし、アーキテクチャの 1 つとして Command と明記する場合は例外です。
