Systems Hungarianの魅力は何ですか？
どの命名ガイドラインに従っていますか？ で、作者はこう言います：
また、Charles Simonyiのハンガリー語表記を使用してコーディングすることを好みます。
私はまだハンガリー語を使用することを好むいくつかのプログラマーに出会いました。そのほとんどはペツォルド/システムズハンガリー語のフレーバーです。 dwLength = strlen(lpszName)を考えてください。
私は 間違ったコードの見た目を間違ったものにする を読み、ドメイン名情報が変数名に含まれているApps Hungarianの根拠を理解しました。しかし、コンパイラタイプを名前に付加することの価値を理解できません。
なぜプログラマーはまだこのスタイルの表記法を使い続けるのですか？慣性だけですか？読みやすさの低下を上回るメリットはありますか？人々はコードを読むときにデコレーターを無視することを学ぶだけですか？そうであれば、どうやって付加価値を付け続けますか？
編集：多くの回答が歴史を説明しています、またはなぜそれがもはや関連していないのですか、どちらも私が引用した記事でカバーされています。
まだ使用している方からの連絡をお待ちしています。なぜそれを使うのですか？それはあなたの基準にありますか？必要ない場合は使用しますか？新しいプロジェクトで使用しますか？何が利点だと思いますか？
現時点では、ハンガリー語を正確に3つの理由、、（== --- ==）で慎重に使用していますそれ以外の場合：
- メンテナンスを行う際に既存のコードベースとの一貫性を保つため。
- コントロール、例えば。 「txtFirstName」。多くの場合、（たとえば）「firstName」の値と「firstName」のコントロールを区別する必要があります。ハンガリー語はこれを行うための便利な方法を提供します。もちろん、「firstNameTextBox」と入力することもできますが、「txtFirstName」の方が理解しやすく、文字数も少なくなっています。さらに、ハンガリー語を使用すると、同じタイプのコントロールを簡単に見つけることができ、IDEでは名前でグループ化されることがよくあります。
- 2つの変数が同じ値を保持するが、型によって異なる場合。たとえば、ユーザーが実際に入力した値の「strValue」と、整数として解析された後の同じ値の「intValue」。
私は確かに自分のアイデアをベストプラクティスとして設定したくありませんが、ハンガリーのコードの保守性を時々使用することでコストはほとんどかからないという経験から、これらのルールに従います。とは言っても、私は自分の実践を常に見直しているので、自分のアイデアが発展するにつれて、何か違うことをするかもしれません。
更新：
私は、Eric Lippertによる 洞察に満ちた記事 を読んだだけで、ハンガリー語が間違ったコードを間違って見えるようにする方法を説明しています。読む価値があります。
私はハンガリー語の表記法を使うのはあまり好きではありませんが、次のように考えています。
- また、コード内のTextBoxを参照する文字列を検索する方が高速であることがわかります。検索ボックスに「txt」と入力します。
すべての要素が独自の名前を持っている反対を想像することはできません。行きたい場所を見つけるのは遅いかもしれませんね。
DropDownListを参照したい場合、ddlでも同じことが言えます。 :)
人々は、この要素がどこにあるかを見つけるためにそれほど多くの時間を費やすことはありません。
プレフィックスの使用は、C＃などの最新の言語コンパイラでは使用できませんが、人間では使用可能（読み取り可能）です。
今月書いた新しいコードで実際にSHを使い始めました。
私の割り当てには、JSでいくつかのPerlコードを書き換えて、Webアプリケーションのクライアント側に移動できるようにする作業が含まれていました。 Perlでは、シギル（$ string、@ array、％hash）のため、通常SHは必要ありません。
JavaScriptでは、SHがデータ構造のタイプを追跡するために非常に貴重であることがわかりました。例えば、
var oRowData = aoTableData[iRow];
これは、整数インデックスを使用してオブジェクトの配列からオブジェクトを取得します。この規則を守ることで、データ型を調べる時間をかなり節約できました。さらに、簡潔な変数名をオーバーロードできます（oRowとiRow）。
tl; dr：弱く型付けされた言語で複雑なコードがある場合、SHは優れている場合があります。ただし、IDEでタイプを追跡できる場合は、それを優先してください。
Apps Hungarian（型システムで表現できないオブジェクトのセマンティックプロパティを示すタグ）は、1980年代初頭の弱く型付けされた言語を使用する際の一般的なエラーに対処するための合理的な方法でした。それらは、今日の強く型付けされた言語ではほとんど目的を果たしません。
Systems Hungarian（オブジェクトの宣言された型を重複して示すタグ）は、コードベースに表面的に均一な外観を課す以外に、目的を果たしたことはありません。これは、Apps Hungarianの意図を誤解し、複雑なコーディングガイドラインによってコードの品質を高めることができると信じていた、技術者以外のマネージャーや経験の浅いプログラマーによって作成および伝播されました。
どちらのスタイルもMicrosoftに由来しています。最近、Microsoftの 命名規則 は「ハンガリー語の表記を使用しないでください」と断固として言っています。
プレフィックスの適切なシステムを考え出すと、キーの磨耗を分散させることができ、キーボードの交換にかかる費用を削減できます。
私はこれを拡張できると思います。私は過去10年間、職場でSHを使用してきました（それが私たちの基準にあるためです）。問題の解決に役立ったことはありません。
その一方で、私は「ホームコード」でほとんど同じくらい長い間、飾り気がないが名前の付いた変数を使用してきました。 SHを見逃したことはありません。
どちらの場所でも、固定サイズのプリミティブ型を必要とするプロトコルコードを記述しました。これは、SHで考えられる最も有益な使用例です。 SHを使用して記述された場合にそれを理解できるようになったわけではなく、SHを使用せずに記述された場合にも邪魔になりませんでした。
結論として、私が見ることができる唯一の違いは、キーボードの摩耗です。
また、その根拠を知りたいです。 IDE型情報のサポートが不足しています。しかし今は？簡単に言えば、これは伝統だと思います。C++コードalwaysこのように見えたので、なぜ変更するのでしょうか？また、ハンガリー語の表記法を使用していた以前のコードに基づいてビルドすると、突然その使用をやめるとかなり奇妙に見えます...
システムハンガリー語の表記は、実際には「型」という用語の誤解であり、ちょっとしたおかしいものでした。システム開発者は、アプリのドメインタイプ（行インデックス、列インデックスなど）ではなく、文字どおりコンパイラタイプ（Word、バイト、文字列、...）としてそれを採用しました。
しかし、私はすべての開発者がその時点で素晴らしいアイデアのように見えるスタイルのいくつかのフェーズを経て（そして接頭辞のタイプは初心者には良いアイデアのように思えます）、その後落とし穴（タイプの変更、新しい、意味のある接頭辞の作成）に入ると思います等）。したがって、慣性があると思います。改善が得られず、なぜそれが不適切な選択であるかを理解できない開発者、実践を義務付けるコーディング標準にこだわった開発者、および<windows.h>。 Microsoftがプレフィックス表記を取り除くように変更するのはコストがかかりすぎます（これは多くの場所で正しくありません：WPARAM？）。
ハンガリー語で人が見落としていることが1つあります。ハンガリー語の表記は、実際にはオートコンプリートで非常に機能します。
変数があり、名前がintHeightOfMonsterだとします。
変数の名前を忘れたとしましょう
HeightOfMonsterまたはMonsterHeightまたはMeasurementMonsterHeight
文字を入力して、オートコンプリートでいくつかの変数名を提案できるようにしたいとします。
HeightOfMonsterがintであることを知っているので、単にiと入力して出来上がりです。
時間を節約する。