Systems Hungarianの魅力は何ですか？[閉まっている]

でガイドラインを命名何が続くのですか？、著者は言います：

また、Charles Simonyiのハンガリー記法を使用してコーディングすることを好みます。

私は、ハンガリー語を使用することを好む複数のプログラマーに出会ったことがありますが、その多くはペツォルド/システムズのハンガリー語です。考えてくださいdwLength = strlen(lpszName)。

私は間違ったコードを間違って見えるようにしましたが、ドメイン名の情報が変数名に含まれているApps Hungarianの原理を理解しています。しかし、コンパイラー型を名前に付加することの価値は理解していません。

なぜプログラマーがこのスタイルの表記法を使用し続けるのですか？それは単なる慣性ですか？可読性の低下を上回る利点はありますか？人々はコードを読むときにデコレータを無視することを学ぶだけなのでしょうか？

編集：多くの答えが歴史を説明している、またはなぜそれがもはや関連していないか、両方とも私が引用した記事でカバーされています。

私はまだそれを使用している世界中の誰からも聞きたいです。なぜそれを使用するのですか？それはあなたの標準にありますか？不要な場合は使用しますか？新しいプロジェクトで使用しますか？利点は何ですか？

現時点では、ハンガリー語を正確に3つの理由で使用していますが、それ以外はすべて慎重に使用しています。

1. メンテナンスを行う際に既存のコードベースと一貫性を保つため。
2. コントロール用 「txtFirstName」。（たとえば）値の「firstName」とコントロールの「firstName」を区別する必要があることがよくあります。ハンガリー語はこれを行う便利な方法を提供します。もちろん、「firstNameTextBox」と入力することもできますが、「txtFirstName」は理解しやすく、文字数も少なくなります。さらに、ハンガリー語を使用すると、同じタイプのコントロールを簡単に見つけることができ、IDEで名前別にグループ化されることがよくあります。
3. 2つの変数が同じ値を保持しているが、タイプが異なる場合。たとえば、実際にユーザーが入力した値の「strValue」と、整数として解析された後の同じ値の「intValue」です。

私は自分のアイデアをベストプラクティスとして設定したくないのは確かですが、ハンガリーの経験により、コードのメンテナンス性がたまに使用されるだけでコストはほとんどかからないため、これらのルールに従います。とは言うものの、私は常に自分の実践を見直しているので、私のアイデアが発展するにつれて何か違うことをするかもしれません。

更新：

Eric Lippertの洞察力に富んだ記事を読んで、ハンガリー語がどのように間違ったコードを間違って見えるようにするのかを説明しました。読む価値があります。

私はハンガリー記法を使うことの大ファンではありませんが、このように考えます：

• また、検索ボックスに「txt」と入力すると、コード内のTextBoxを参照する文字列をすばやく見つけることができます。

すべての要素が独自の名前を持っている逆を想像してはいけません。行きたい場所を見つけるのが遅くなるかもしれませんよね？

DropDownListを参照したい場合、ddlについても同じことが言えますか、それは簡単ですか？:)

人々は、この要素がどこにあるかを見つけるのにそれほど時間を費やすことはありません。

プレフィックスの使用は、C＃のような最新の言語コンパイラでは使用できませんが、人間にとっては使用可能（読み取り可能）です。

Apps Hungarian（型システムでは表現できないオブジェクトのセマンティックプロパティを示すタグ）は、1980年代初期の弱く型付けされた言語を使用する場合の一般的なエラーに対処するための合理的な方法でした。これらは、今日の強く型付けされた言語ではほとんど役に立たない。

Systems Hungarian（オブジェクトの宣言された型を重複して示すタグ）は、コードベースに表面的に均一な外観を課すことを除いて、いかなる目的も果たしていません。Apps Hungarianの意図を誤解し、複雑なコーディングガイドラインによってコードの品質が向上する可能性があると信じていた、非技術的なマネージャーと経験の浅いプログラマーによって作成および伝播されました。

どちらのスタイルもMicrosoft内で作成されました。最近では、Microsoftの命名規則は「ハンガリー語表記を使用しないでください」と明確に述べています。

適切なプレフィックスのシステムを考え出せば、キーの摩耗を広げることができます。これにより、交換用キーボードの費用を削減できます。

これを拡張できると思います。私は職場でSHを最後の10年間かそこらで使用しました（標準になっているため）。問題の解決に役立ったことはありません。

一方、私は「ホームコード」で、ほとんど同じくらい長い間、飾り付けられていないが、よく知られた変数を使用しました。SHを見逃したことはありません。

両方の場所で、固定サイズのプリミティブ型を必要とするプロトコルコードを記述しました。これは、SHで考えられる最も有益な使用例です。SHで書かれたときに私が伝えることができることは助けになりませんでしたし、SHなしで書かれたときに私を妨げませんでした。

したがって、結論として、私が見ることができる唯一の違いは、キーボードの摩耗です。

私は実際に、今月書いた新しいコードでSHを使い始めました。

私の割り当てでは、JSでPerlコードを書き換えて、Webアプリケーションのクライアント側に移動できるようにしました。Perlでは、シギル（$ string、@ array、％hash）のため、SHは通常必要ありません。

JavaScriptでは、データ構造のタイプを追跡するためにSHが非常に貴重であることがわかりました。例えば、

var oRowData = aoTableData[iRow];

これは、整数インデックスを使用してオブジェクトの配列からオブジェクトを取得します。この規則を順守することで、データ型を調べる時間をかなり節約できました。さらに、簡潔な変数名をオーバーロードできます（oRowvs. iRow）。

tl; dr：弱い型付けの言語で複雑なコードを使用している場合、SHは素晴らしいものになります。ただし、IDEで型を追跡できる場合は、それをお勧めします。

理論的根拠にも興味があります。彼らが過去にそれを使用した理由を知っています：型情報に対するIDEサポートの欠如。でも今？簡単に言えば、それは伝統だと思います。C ++コードは常にこのように見えたのに、なぜ物事を変えるのですか？その上、ハンガリー語表記を使用した以前のコードの上に構築すると、突然その使用をやめると非常に奇妙に見えます...

Systems Hungarian表記は、実際にはちょっとしたコックアップであり、「タイプ」という用語の誤解でした。システム開発者は、アプリのドメインタイプ（行インデックス、列インデックス、...）ではなく、文字通りコンパイラタイプ（ワード、バイト、ストリング、...）としてそれを受け入れました。

しかし、すべての開発者は落とし穴（タイプの変更、新しい意味のあるプレフィックスの作成、等）。だから私は慣性があると思う：良くならない開発者から、なぜそれが貧弱な選択であるかを理解する開発者から、実践を義務付けるコーディング標準に固執する開発者から、そしてを使用する人々から<windows.h>。マイクロソフトがプレフィックス表記を取り除くために変更するにはコストがかかりすぎます（多くの場所で間違っています：WPARAM？）。

ハンガリー語で人々が見逃していることが一つあります。ハンガリー語の表記法は、実際にオートコンプリートを使用して優れた機能を発揮します。

変数があるとします。名前はintHeightOfMonsterです。

変数の名前を忘れたとしましょう

heightOfMonsterまたはMonsterHeightまたはMeasurementMonsterHeightになります

文字を入力して、オートコンプリートでいくつかの変数名を提案できるようにしたい場合。

heightOfMonsterがintであることを知っているので、「i」と「ほら」と入力するだけです。

時間を節約する。