なぜ「ハンガリー記法」を使うべきではないのですか？
私はハンガリー語が何を指すか知っています-変数、パラメーター、またはタイプに関する情報をその名前の接頭辞として与えます。場合によってはそれが良い考えのように思われるとしても、誰もがそれに対して猛烈に反対しているようです。有用な情報が伝えられていると感じたら、それを利用可能な場所に置いてはいけないのはなぜですか？
ほとんどの人は、ハンガリーの表記法を間違った方法で使用し、間違った結果を得ています。
Joel Spolskyによる次のすばらしい記事を読んでください： 間違ったコードの見た目を間違ったものにする 。
要するに、変数名の前にtype（文字列）（Systems Hungarian）を付けるハンガリー記法は役に立たないので悪いです。
作成者が意図したハンガリー表記法で、変数名の前にkind（Joelの例：安全な文字列または安全でない文字列を使用）を付けることで、Apps Hungarianと呼ばれる用途があり、まだ価値があります。
vハンガリーの表記法を使用するvcodeは、ncode adjの読み取りを困難にします。
ジョエルは間違っています、そして、ここに理由があります。
彼が話している「アプリケーション」情報型システムでエンコードされるべきです。安全なデータを必要とする関数に安全でないデータを渡さないようにするために、変数名の反転に依存しないでください。 不可能になるように型エラーにする必要があります。安全でないデータは、安全な関数に渡せないように、安全でないとマークされた型を持つ必要があります。安全でないものから安全なものに変換するには、何らかのサニタイズ機能を使用した処理が必要です。
ジョエルが「種類」と呼ぶものの多くは種類ではありません。実際、それらはタイプです。
ただし、ほとんどの言語に欠けているのは、この種の区別を強制するのに十分な表現力のある型システムです。たとえば、Cに一種の「強いtypedef」（typedef名には基本型のすべての操作がありますが、変換できない）がある場合、これらの問題の多くはなくなります。たとえば、strong typedef std::string unsafe_string;と言って、std :: stringに変換できない（したがって、オーバーロード解決などに参加できる）新しい型unsafe_stringを導入できる場合は、愚かなプレフィックスは必要ありません。
したがって、ハンガリー語は型ではないものを対象としているという中心的な主張は間違っています。型情報に使用されています。確かに、従来のC型情報よりも豊富な型情報。オブジェクトの目的を示すために、ある種の意味の詳細をエンコードするのは型情報です。しかし、それはまだ型情報であり、適切な解決策は常に型システムにエンコードすることです。それを型システムにエンコードすることは、ルールの適切な検証と施行を得る最良の方法です。変数名は単にマスタードをカットしません。
言い換えれば、目的は「間違ったコードを開発者に間違って見えるようにする」ことではありません。 「間違ったコードを間違って見えるようにしますコンパイラにとって」。
それはソースコードを非常に混乱させると思います。
また、強く型付けされた言語ではあまり得られません。何らかの形式の不一致のtomfooleryを行うと、コンパイラーがそれについて通知します。
ハンガリー語表記は、言語でのみ意味がありますユーザー定義型なし。最新の関数型言語またはオブジェクト指向言語では、値の「種類」に関する情報を変数名ではなくデータ型またはクラスにエンコードします。
いくつかの回答の参照 Joelsの記事 。ただし、彼の例はVBScriptであり、ユーザー定義クラスをサポートしていません（少なくとも長い間）。ユーザー定義型のある言語では、HtmlEncodedString-typeを作成して同じ問題を解決し、Writeメソッドにそれだけを許可させます。静的に型付けされた言語では、コンパイラはエンコーディングエラーをキャッチします。動的に型付けされた言語ではランタイム例外が発生しますが、いずれにしても、エンコードされていない文字列の書き込みから保護されます。ハンガリー語の表記法は、プログラマーを人間のタイプチェッカーに変えるだけで、通常はソフトウェアでより適切に処理される仕事です。
Joelは「systems hungarian」と「apps hungarian」を区別します。「systems hungarian」はint、floatなどの組み込み型をエンコードし、「apps hungarian」はより高いレベルのメタ情報である「kinds」をエンコードしますマシンタイプの変数について、OOまたは現代の関数型言語ではユーザー定義タイプを作成できるため、この意味でタイプと「種類」の区別はありません。両方ともタイプで表すことができますシステム-そして「アプリ」ハンガリー人は「システム」ハンガリー人と同じくらい冗長です。
したがって、あなたの質問に答えるには：Systems hungarianは、安全ではなく、型付けの弱い言語でのみ役に立ちます。 float値をint変数に割り当てると、システムがクラッシュします。 60年代には、ハンガリー語表記法が BCPL で使用するために特別に考案されました。これは、まったく型チェックを行わない、かなり低レベルの言語です。今日一般的に使用されている言語にこの問題があるとは思いませんが、表記は一種の カーゴカルトプログラミング として生き続けました。
ハンガリーのアプリは、レガシーVBScriptや初期バージョンのVBなど、ユーザー定義型のない言語で作業している場合に意味があります。おそらく、PerlとPHPの初期バージョンもあります。繰り返しますが、現代の言語でそれを使用することは純粋なカーゴカルトです。
他の言語では、ハンガリー語はjustく、冗長で、脆弱です。型システムから既知の情報を繰り返し、 自分自身を繰り返すべきではありません 。型のこの特定のインスタンスの意図を説明する変数の説明的な名前を使用します。型システムを使用して、変数の「種類」または「クラス」に関する不変式とメタ情報をエンコードします。タイプ。
Joelsの記事の一般的なポイント-間違ったコードを間違って見えるようにする-は、非常に良い原則です。ただし、バグに対するさらに優れた保護は、可能な場合はコンパイラによって自動的に検出される誤ったコードを持つことです。
私はすべてのプロジェクトで常にハンガリー語の表記法を使用しています。何百もの異なる識別子名を扱っているとき、それは本当に役立ちます。
たとえば、文字列を必要とする関数を呼び出すと、「s」と入力してcontrol-spaceを押すと、IDEに「s」で始まる変数名が正確に表示されます。
もう1つの利点は、uをunsignedに、iをsigned intにプレフィックスすると、潜在的に危険な方法で符号付きと符号なしが混在している場所がすぐにわかります。
巨大な75000行のコードベースで、ローカル変数をそのクラスの既存のメンバー変数と同じ名前にしたために（私も他の人も）バグが発生した回数を思い出せません。それ以来、私は常にメンバーの前に「m_」を付けます
その味と経験の問題。試してみるまでノックしないでください。
この情報を含める一番の理由を忘れています。プログラマーとは関係ありません。会社を辞めた2年か3年後にそのことを読まなければならない人と関係があります。
はい、IDEはタイプをすばやく識別します。ただし、「ビジネスルール」コードのいくつかの長いバッチを読んでいるときは、各変数で一時停止しなくてもよいので、それがどのタイプであるかを知ることができます。 strUserID、intProduct、またはguiProductIDなどが表示されると、muchが「ランプアップ」時間を短縮します。
私は、MSがそれらの命名規則のいくつかとあまりに行き過ぎたことに同意します-私はそれを「あまりにも良いこと」の山に分類します。
命名規則は、あなたがそれらに固執するのであれば、良いことです。過去の仕事で呼ばれたように、「キャメルケース」をプッシュするほど多くの同様の名前の変数の定義を常に確認する古いコードを十分に調べました。現在、私はVBScriptで何千行もの完全にコメントを外したクラシックASPコードの仕事をしていますが、物事を解明しようとする悪夢です。
各変数名の先頭に隠された文字を追加する必要はなく、変数名だけでは説明的ではないことがわかります。ほとんどの言語では、とにかく宣言時に変数の型が必要なので、その情報はすでに利用可能です。
また、メンテナンス中に変数の型を変更する必要がある状況もあります。例：「uint_16 u16foo」として宣言された変数が64ビット符号なしになる必要がある場合、次の2つのいずれかが発生します。
- 各変数名を調べて変更します（同じ名前の無関係な変数をホースしないようにしてください）、または
- タイプを変更するだけで、名前を変更しないでください。混乱を引き起こすだけです。
Joel Spolskyはこれについての良いブログ記事を書いています。 http://www.joelonsoftware.com/articles/Wrong.html 基本的に、まともなIDEがタイプしたいと言ったときにコードを読みにくくしないようにすることです。変数は覚えていない場合です。また、コードを十分に区分化した場合、変数が3ページ上として宣言されたものを覚えておく必要はありません。
最近のタイプよりスコープは重要ではありません。
* l for local
* a for argument
* m for member
* g for global
* etc
古いコードをリファクタリングする最新の手法では、シンボルのタイプを変更したためにシンボルの検索と置換が面倒であるため、コンパイラはタイプの変更をキャッチしますが、スコープの誤った使用をキャッチしないことがよくあります。
ハンガリー語表記を正しい使用しない理由はありません。人気がないのは、特にWindows APIでのハンガリー語表記のmis-useに対する長時間の反発によるものです。
古くは、DOSにIDEに似たものが存在する前に（Windowsでコンパイラを実行するのに十分な空きメモリがないため、開発はDOSで行われていました）マウスを変数名の上に置いても何の助けも得られません。 （マウスがあると仮定します。）対処しなければならなかったのは、すべてが16ビット整数（Word）または32ビット整数（LONG Word）として渡されるイベントコールバック関数でした。次に、これらのパラメーターを特定のイベントタイプに適したタイプにキャストする必要がありました。実際、APIの多くは事実上型がありませんでした。
結果は、次のようなパラメーター名を持つAPIです。
LRESULT CALLBACK WindowProc(HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam);
WParamとlParamという名前は、かなりひどいものの、実際にはparam1とparam2という名前よりも悪くないことに注意してください。
さらに悪いことに、Window 3.0/3.1には2種類のポインターがありました。そのため、たとえば、メモリ管理関数LocalLockからの戻り値はPVOIDでしたが、GlobalLockからの戻り値はLPVOID（「L」が長い）でした。そのひどい表記法は拡張され、l ong p ointer文字列の前にlpが付けられ、単にmallocであった文字列と区別されました'd。
この種のことに対して反発があったことは驚くことではありません。
ハンガリー語表記法は、開発者が特定の変数がどのように使用されているかをすぐに思い出させるので、コンパイル時の型チェックのない言語で役立ちます。パフォーマンスや動作には影響しません。これはコードの読みやすさを改善するためのものであり、ほとんどは好みとコーディングスタイルの問題です。このまさに理由で、多くの開発者によって批判されています-誰もが脳内に同じ配線を持っているわけではありません。
コンパイル時の型チェック言語の場合、ほとんど役に立ちません。数行上にスクロールすると、宣言が表示されるため、型が表示されます。グローバル変数またはコードブロックが複数の画面にわたっている場合、Graveの設計と再利用性の問題があります。したがって、批判の1つは、ハンガリー語表記法により、開発者が悪いデザインを持ち、簡単にそれを回避できることです。これはおそらく嫌われの理由の一つです。
一方、コンパイル時の型チェック言語でさえハンガリー語表記の恩恵を受ける場合があります-voidポインターまたはwin32 APIのHANDLE 's 。これらは実際のデータ型を難読化するので、ハンガリー語表記を使用するメリットがあるかもしれません。ただし、ビルド時にデータの種類を知ることができる場合、適切なデータ型を使用しないのはなぜですか。
一般的に、ハンガリー記法を使用しない理由は特にありません。いいね、ポリシー、コーディングスタイルの問題です。
Pythonプログラマーとして、ハンガリー語表記法はかなり速く崩壊します。 Pythonでは、何かis文字列かどうかは気にしません-できるかどうかact like文字列（つまり、___str___()メソッドがある場合）文字列を返します）。
たとえば、整数としてfooがあり、12
foo = 12
ハンガリー語表記では、iFooまたは何かを呼び出して整数であることを示す必要があるため、後でそれが何であるかがわかります。 Pythonを除いて、それは機能しません。むしろ、意味がありません。 Pythonでは、使用するときに必要な型を決定します。文字列が必要ですか？私がこのようなことをしたら
print "The current value of foo is %s" % foo
%s-文字列に注意してください。 Fooは文字列ではありませんが、%演算子はfoo.___str___()を呼び出し、結果を使用します（存在すると仮定します）。 fooはまだ整数ですが、文字列が必要な場合は文字列として扱います。フロートが必要な場合は、フロートとして扱います。 Pythonのような動的に型付けされた言語では、ハンガリー語表記法は意味がありません。使用するまではどのような型でもかまいません。特定の型が必要な場合は、その型にキャストしてください（例：float(foo)）使用するとき。
PHPのような動的言語にはこの利点はありません-PHPは、ほとんど誰も覚えていない曖昧なルールセットに基づいて、バックグラウンドで「正しいこと」をしようとします。 、これはしばしば壊滅的な混乱をもたらします。この場合、$files_countや$file_nameなどの何らかの命名メカニズムが便利です。
私の考えでは、ハンガリー記法はヒルに似ています。過去には有用だったかもしれませんし、少なくとも有用だと思われたかもしれませんが、最近ではあまり多くの利点が得られないため、余分なタイピングがたくさんあります。
IDEはその有用な情報を伝える必要があります。 IDEの進歩がそれほど進んでいなかったとき、ハンガリー人は何らかの意味（全体ではなく、ある種）を意味していたかもしれません。
Apps Hungarianは私にとってギリシャ語です-良い意味で
プログラマとしてではなくエンジニアとして、私はすぐにApps Hungarianのメリットに関するJoelの記事に行きました： "Mrong Wrong Code Look Wrong" 。私はApps Hungarianが好きです。なぜなら、工学、科学、数学が下付きおよび上付き記号（ギリシャ文字、数学演算子など）。 Newton's Law of Universal Gravity ：の特定の例を見てみましょう：最初に標準の数学表記で、次にApps Hungarian擬似コードで：
frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)
数学表記では、最も顕著なシンボルは、変数に格納されている情報のkindを表すものです：力、質量、位置ベクトルなど。何の位置？これはまさにApps Hungarianが行っていることです。最初に変数に格納されているもののkindを示してから、詳細を取得します。最も近いコードについては、数学表記に到達できます。
明らかに強い型付けにより、Joelのエッセイの安全な文字列と安全でない文字列の例を解決できますが、位置ベクトルと速度ベクトルに別々の型を定義することはできません。どちらもサイズ3の二重配列であり、一方に行う可能性のあるものはすべて他方に適用される可能性があります。さらに、位置と速度を連結する（状態ベクトルを作成する）か、それらの内積をとることは完全に理にかなっていますが、おそらくそれらを追加することはできません。どのように入力すると最初の2つが許可され、2つ目が禁止され、そのようなシステムは保護したいすべての可能な操作にどのように拡張されますか？タイピングシステムですべての数学と物理学をエンコードするつもりがない限り。
さらに、多くのエンジニアリングは、Matlabのような弱く型付けされた高レベル言語、またはFortran 77やAdaのような古い言語で行われます。
したがって、あなたが派手な言語とIDEを持ち、Apps Hungarianがそれを忘れないなら、多くの人が持っているようです。しかし、私にとっては、弱いまたは動的に型付けされた言語で作業している初心者プログラマーよりも悪いので、Apps Hungarianを使用すると、使用しない場合よりも速くより良いコードを作成できます。
ハンガリー記法の利点を暴く
- 変数を区別する方法を提供します。
1つの値を別の値と区別するのがタイプだけである場合、あるタイプから別のタイプへの変換にのみ使用できます。型間で変換される同じ値がある場合、変換専用の関数でこれを実行する必要がある可能性があります。 （ハンガリーのVB6の残り物は、JSONオブジェクトをデシリアライズする方法がわからなかったり、null可能型を宣言または使用する方法を適切に理解できなかったために、すべてのメソッドパラメーターで文字列を使用しているのを見ました）ハンガリー語の接頭辞のみで区別される2つの変数があり、一方から他方への変換ではない場合は、それらを使用して意図を詳しく説明する必要があります。
- コードを読みやすくします。
ハンガリー語の表記法は、変数名で人々を怠zyにすることを発見しました。彼らはそれを区別する何かを持っています、そして、彼らはその目的を詳述する必要を感じません。これは、ハンガリーの表記コードと現代の典型的なものです：sSQLとgroupSelectSql（、または以前の開発者によって入力されたORMを使用することになっているため、通常はsSQLはありません。 ）、sValue vs.formCollectionValue（または通常sValueもありません。これらはたまたまMVCにあり、モデルバインディング機能を使用する必要があるためです）、sType vs. publishSourceなど。
読みやすくすることはできません。ハンガリーのVB6の残り物のsTemp1、sTemp2 ... sTempNは、他のすべての人が結合したものよりも多く見られます。
- エラーを防ぎます
これは、番号2によるもので、これは誤りです。
Joelの記事は素晴らしいですが、1つの主要な点を省略しているようです。
ハンガリー語は、特定の「アイデア」（種類+識別子名）をコードベース全体（非常に大きなコードベースであっても）で一意またはほぼ一意にします。
これは、コードのメンテナンスにとって非常に大きなものです。つまり、適切なol '単一行テキスト検索（grep、findstr、' find in all files '）を使用して、その' idea 'のすべての言及を見つけることができます。
コードの読み方を知っているIDEがあるのに、なぜそれが重要なのでしょうか？彼らはまだそれがあまり得意ではないからです。これは小さなコードベースでは見にくいですが、大きなコードベースでは明らかです-「アイデア」がコメント、XMLファイル、Perlスクリプト、およびソース管理外の場所（ドキュメント、wiki、バグデータベース）で言及される場合.
ここでも少し注意する必要があります-例えばC/C++マクロでトークンを貼り付けると、識別子の言及を隠すことができます。このような場合はコーディング規約を使用して対処できますが、いずれにしてもコードベース内の少数の識別子のみに影響を与える傾向があります。
追伸型システムを使用するかハンガリー語を使用するかについては、両方を使用するのが最善です。コンパイラがあなたのためにそれをキャッチしない場合にのみ、間違って見える間違ったコードが必要です。コンパイラーにキャッチさせることが不可能な場合がたくさんあります。しかし、それが実現可能な場合-はい、代わりにそれをしてください！
ただし、実行可能性を検討する場合は、タイプを分割することの悪影響を考慮してください。例えばC＃では、「int」を非組み込み型でラップすると大きな影響があります。そのため、状況によっては意味がありますが、すべての状況で意味があるわけではありません。
私はいつも、正しい場所に1つまたは2つの接頭辞を付けても痛くないと考えてきました。 IEnumerableのように、「ちょっとこれはインターフェイスだから、特定の振る舞いに頼らないで」など、何か有用なものをすぐに伝えられると思います。コメントは、1文字または2文字の記号だけでなく、物事を混乱させる可能性があります。
それは信じられないほど冗長であり、ほとんどの最新のIDEでは役に立ちません。
加えて、私にとっては、intI、strUserNameなどを見るだけで迷惑です:)
有用な情報が伝えられていると感じたら、それを利用可能な場所に置いてはいけないのはなぜですか？
それでは、誰が他の人の考えを気にしますか？便利だと思う場合は、表記法を使用してください。
私の経験では、悪い理由は次のとおりです。
1-変数の型を変更する必要がある場合（つまり、32ビット整数を64ビット整数に拡張する必要がある場合）、すべてのコードを中断します;
2-これは、型がすでに宣言に含まれているか、実際の型がそもそもそれほど重要ではない動的言語を使用しているため、役に立たない情報です。
さらに、汎用プログラミングを受け入れる言語（関数を記述するときに一部の変数の型が決定されない関数）または動的型付けシステム（つまり、コンパイル時に型が決定されない場合）では、どのように名前を付けますか変数？そして、制限された形式であっても、ほとんどの現代言語はどちらか一方をサポートします。
IDEのアルファベット順のプルダウンリストにコントロールのリストが表示される場合、フォーム上のコントロール（btnOK、txtLastNameなど）に名前を付けるための便利な規則です。
Joel SpolskyのMakeing Wrong Code Wrong 彼は、誰もがハンガリー語表記（彼がSystems Hungarianと呼んでいる）と考えるものは、本来意図されていたもの（彼がApps Hungarianと呼んでいるもの）ではないことを説明しています。この議論を見るには、I'm Hungaryの見出しまでスクロールします。
基本的に、Systems Hungarianは価値がありません。コンパイラやIDEがあなたに伝えるのと同じことを伝えるだけです。
Apps Hungarianは、変数の意味を説明し、実際に役立つ場合があります。
ASP.NETサーバーコントロールでハンガリー語表記を使用する傾向がありますonly、そうでない場合、フォーム上のコントロールが何であるかを判断するのが難しすぎます。
このコードスニペットをご覧ください。
<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />
ハンガリー語を使わずにそのコントロール名のセットを持っているより良い方法を誰かが示すことができれば、私はそれに移動したいと思うでしょう。
マスターの言葉で：
http://www.joelonsoftware.com/articles/Wrong.html
いつものように興味深い読書。
抽出物：
「どこかで、誰かがシモニーの論文を読んで、彼は「タイプ」という言葉を使った。彼は、コンパイラが行う型チェックのように、型システムのようにクラスのような型を意味すると思った。彼はしなかった。 「タイプ」という言葉が彼の意図したとおりでしたが、助けにはなりませんでした。
「しかし、Apps Hungarianには非常に大きな価値があります。コードのコロケーションが増加するため、コードの読み取り、書き込み、デバッグ、保守が容易になり、最も重要なのは、間違ったコードが間違っているように見えることです。」
Joel On Softwareを読む前に時間があることを確認してください。 :)
いくつかの理由：
- 現代のIDEは、マウスを変数の上に置くだけで変数タイプを提供します。
- ほとんどの型名は、プレフィックスとして合理的に使用されるほど長い（HttpClientRequestProviderと考えてください）。
- 型情報にはright情報は含まれません。目的変数（myIntegervs.pageSize）.
私は誰もがそれに反対しているとは思わない。静的型のない言語では、非常に便利です。まだタイプにない情報を提供するために使用される場合、私は間違いなくそれを好みます。 Cの場合と同様、char * szNameは、変数がnullで終了する文字列を参照することを示しています-char *では暗黙的ではありません-もちろん、 typedefも役立ちます。
Joelには、ハンガリー語を使用して変数がHTMLエンコードされているかどうかを判断する素晴らしい記事がありました。
http://www.joelonsoftware.com/articles/Wrong.html
とにかく、ハンガリー語が既に知っている情報を伝えるために使用されるとき、私はハンガリー語を嫌う傾向があります。
もちろん、プログラマの99％が何かに同意する場合、何か問題があります。ここで彼らが同意する理由は、彼らのほとんどがハンガリー語表記を正しく使用したことがないためです。
詳細な議論については、このテーマに関するブログ投稿を参照してください。
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html
ハンガリー記法が発明された頃からコーディングを始めており、嫌いなプロジェクトで初めて使用することを余儀なくされました。
しばらくして、それが適切に行われたとき、それが実際に助けになり、最近はそれが大好きだと気づきました。
しかし、すべてのものが良いことであるように、それは学習され理解されなければならず、それを適切に行うには時間がかかります。
美的側面は誇張されすぎているのすべてだと思います。それが最も重要なことであれば、私たちは自分自身をdevelopersではなく、グラフィックdesignersと呼びます。
1つの重要な部分は、オブジェクトの役割が何であるかではなく、それが何であるかを説明することです。別の文脈で、自分自身をHumanDustmanとは呼ばないので、最も重要なのは人間ではないでしょう。
リファクタリングの目的にとっても重要です。
public string stringUniqueKey = "ABC-12345";
文字列の代わりにGUIDを使用することにした場合、参照するすべてのコードをリファクタリングした後、変数名は愚かに見えます。
または：
public int intAge = 20;
これをフロートに変更すると、同じ問題が発生します。等々。
ハンガリー語の表記法は、特にMicrosoftによって悪用され、変数名よりも長いプレフィックスをもたらし、特に型（Win16では異なる型/サイズ、Win32では同一の悪名高いlparam/wparam）を変更すると、非常に厳格になります）。
したがって、この乱用とM $による使用の両方のため、それは役に立たないとされました。
私の仕事ではJavaでコーディングしていますが、創設者はMFCの世界から来たので、同様のコードスタイルを使用します（整列ブレース、私はこれが好きです！メソッド名に大文字、私はそれに慣れています、クラスメンバーにm_のようなプレフィックス（フィールド）、s_から静的メンバーなど）。
そして、彼らはすべての変数がそのタイプを示す接頭辞を持つべきだと言った（例えば、BufferedReaderはbrDataという名前です）。型は変更できますが、名前は従わないため、コーダーはこれらのプレフィックスの使用に一貫性がないため、これは悪い考えとして示されました（aBuffer、theProxyなども見かけます！）。
個人的に、私は便利だと思ういくつかのプレフィックスを選択しました。最も重要なのは、ブール変数をプレフィックスするbです。これは、if (bVar)のような構文を許可する唯一のものであるためです（一部の値のtrueまたはfalse）。 Cでコーディングするときは、後で解放する必要があることを念頭に置いて、mallocで割り当てられた変数にプレフィックスを使用しました。等。
したがって、基本的に、この表記法全体を拒否するのではなく、自分のニーズに合っていると思われるものを採用しました。
そしてもちろん、いくつかのプロジェクト（作業、オープンソース）に貢献するとき、私は単に慣例に従っているだけです！
長年、私はプログラミングでハンガリー語の表記法を使用していました。いくつかの視覚的な混乱と、データ型を変更したときにプレフィックスを変更するタスクを除いて、誰も私を納得させることはできませんでした。最近まで、同じソリューションで既存のC＃とVB.NETアセンブリを組み合わせる必要があったとき。
結果：「fltSomeVariable」を「sngSomeVariable」メソッドパラメータに渡す必要がありました。 C＃とVB.NETの両方でプログラムを作成している人でさえ、私は不意を突かれ、少しの間休息させられました。 （C＃とVB.NETは、同じデータ型を表すために異なる名前を使用することがあります。たとえば、floatとsingleです。）
次に、これを考慮してください。多くの言語から呼び出し可能なCOMコンポーネントを作成したらどうでしょうか。 VB.NETおよびC＃の「変換」は、.NETプログラマーにとって簡単でした。しかし、C++またはJavaで開発している人はどうでしょうか？ 「dwSomeVariable」は、C++に慣れていない.NET開発者にとって何か意味がありますか？
言われずに変数のタイプがわからない場合は、とにかくそれをいじってはいけません。
タイプはそれほど重要ではないかもしれません。メソッドが何をしているのかを知っていれば、変数で何が行われているかを把握でき、プログラムが何をしているのかわかります
必要な場合があります。型が重要で、宣言が近くにない場合、または型を簡単に推測できない場合。しかし、絶対に見られるべきではありません
- 彼らは巨大な目障りです
- IDEは、変数の型について知っておく必要があることすべてを伝えることができるはずです。
- 良い名前（HNが邪魔をする）は、変数について知る必要がある他のすべてを伝える必要があります。
ハンガリー語は、一部のタイプ情報と引き換えに変数名から貴重な文字を取り去るので悪いのですか？
まず第一に、強く型付けされた言語では、本当に馬鹿げたことをするとコンパイラは警告を出します。
第二に、優れたモジュール化されたコードを信じており、1つの関数であまり多くの作業を行わない場合、変数はいずれにせよ使用されるコードのすぐ上で宣言されている可能性があります（したがって、そこに型があります）。
第三に、すべてのポインターの先頭にpを、すべてのクラスの先頭にCを付けると、ニースのモダンなIDEのインテリセンス機能が本当に台無しになります（入力するクラス名を入力し、取得するとすぐに推測する機能を知っています）正しいEnterキーを押すと完了しますか？まあ、すべてのクラスの先頭にCを付けると、少なくとも1つ余分に入力する必要があります）...
メンバー変数にはどのようなプレフィックスを使用しますか？ も参照してください。
リンクが見つかりませんが、ハンガリーの表記法を避けることでプログラミングスタイルが向上することを読んだことを覚えています（これに同意します）。
プログラムのステートメントをプログラムするときは、メソッドを呼び出す前に「このオブジェクトの種類」について考えるのではなく、「何をしたいのか」「どのメッセージを送信するのか」を考える必要があります「。
説明するための漠然とした概念の種類が、私はそれが動作すると思います。
たとえば、変数customerNameに顧客名が格納されている場合、それが文字列であるか他のクラスであるかは気にする必要はありません。このオブジェクトから何を望むかを考えることはより重要です。それをprint（）、getFirstName（）、getLastName（）、convertToString（）などにしたいですか？それをStringクラスのインスタンスにして、許可されたものにすると、すべてを構築する必要があるため、自分とデザインを制限しますコードの他の場所で必要な他のロジック。