ハンガリアン記法の無駄について（改訂版w

VB6.0以前はむしろマイクロソフトの資料やヘルプなどでも多用されていたハンガリアン記法 *1ですが、Visual Studio.NET 2003が出たときにマイクロソフトはサンプル等からこの記法を一掃しました。もちろん、マイクロソフトが言うから、という理由ではなく、それなりに理由があるためほとんど使われなくなったこの記法について、なぜ無駄なのかを自分の周囲における状況や、過去の体験ベースでまとめてみようと思います。別に、学術的な考察でも何でも無いので異論反論あるかと思いますが、その辺は適当に解釈してください。

理由

区別する必要が無いものを区別するのは無駄。.NETでは登場するソースのかたまりはほとんどがクラスなので、クラスソースファイル名の頭に「Cls」等つける意味が無い。
- 略称を考える/管理する労力が無駄。クラスはいわばすべて「型」。厳密にハンガリアン記法を適用するなら、クラスごとに略称を考える必要があるが、非現実的。
- 区別する必要がないものに全部同じ名前を付けるのは無駄。
- 実態にそぐわない命名、過去に引きずられた命名は無駄。VB6.0ではクラスインスタンスに「obj」と付けることが多かったが、こちらも.NETではほとんどの変数が参照型のオブジェクト。また、値型扱いのIntegerやLongも、実態は構造体（構造体は値型なので、振る舞いは値型）。構造体の命名規則があったとしたら、Int32整数は「構造体」のプリフィックスをつけなければいけないことになる。

フォームクラスも所詮はクラス。フォームクラスは若干特殊だが、それもVisual Studio上でアイコン等が異なるため、誤読することはない（Frm、と頭に付ける方式に対して）。

環境が進化洗練されているのに古い環境想定の仕組みを使うのは無駄。高機能なツール、広いディスプレイがある状況で、変数の型を文字で付記するのは無駄。別の方法で確認はいくらでもできる。
- Long型などを表しがちな「エル」などはむしろ数字の1と混同する
- Visual Studioでマウスを合わせたり定義参照すれば型名などすぐわかる。

開発プラットフォームを提供しているマイクロソフト自体も推奨していないのにそれを使い続けるのは無駄。これはMSに追従しろという話ではない。MSが推奨していないということは、無理にハンガリアンを導入することで標準やサードパーティライブラリ、自社内でのソース流用時に規約がバラバラになる可能性がある。
- 他で使っているライブラリや製品を使った場合に、命名規則が混在してむしろ混乱しやすい。
- 他の開発者が入ってきたときに、この案件でのルールを覚える手間がでる。

変数宣言だけでなく型に合わせて名前まで変えないといけないなんて無駄すぎる。変数の型が変わったときや大きな変更を入れた際に、変数名の先頭についた型名文字列を直し忘れてむしろ混乱するケースが過去にあった。
- 直すべきは宣言上の型だけで十分。名前まで変えないといけないのはむしろ変更開発を行うことになった際に障壁になる（変数やクラス名の変更はコストが大きい）。

末尾のリンク先で他の人も言っていますが、自分が扱っているソースのメソッド内などでスコープや型をプリフィックス（接頭語）に書かないと「いけない」状況というのは、なにか他の根本的な問題を抱えている場合が多いと思います。

逆に、メリットは無いのか？

指摘ばかりは不平等なので、メリットも探しましょう。上記文中にもヒントを書きましたが、以下のような場合は（仕方なく）ハンガリアン記法もありだとおもいますよ。あくまで、自分用の「マーク」として、くらいのとらえ方が無難だと思いますが。結局のところ、「ルールを周知徹底させるコストに結果が見合うか」なんですよね。

貧弱な開発環境。
- スクリプト言語等でテキストエディタを用いた開発などではこれが無いと逆に辛いかもしれない。
- 高機能エディタを使えない客先の現場環境などではプリフィックスがあったほうがわかりやすいことがあるかもしれない。

上記のようなケースでは、たいてい変数の型数も少なくシンプルであることが多いので、ハンガリアン記法にしても略記対応表を作るまでも無く、読み解けたりします。要するに、ケースバイケースです。こういうのが向いているなら使えばよい、向いていないなら、むしろ使うことで手間が出るならやめるべき、それだけのことですね。