language-agnostic - なぜ「ハンガリアン記法」を使わないのですか？

Question

私はハンガリー語が何を指しているのか知っています-変数、パラメーター、またはタイプに関する情報をその名前の接頭辞として提供します。場合によってはそれが良い考えであるように思われるとしても、誰もがそれに激しく反対しているようです。有用な情報が伝えられていると感じたら、それを入手可能な場所に置いてはいけないのはなぜですか。

参照：人々は現実の世界でハンガリー語の命名規則を使用していますか？

score 276 · Accepted Answer

276

vadjHungarian 注釈を使用すると、vncode の読み取りが困難になります。

于 2008-09-21T20:45:20.803 に答える

score 174 · Accepted Answer

ほとんどの人はハンガリアン記法を間違った方法で使用し、間違った結果を得ています。

Joel Spolskyによるこの優れた記事を読んでください：間違ったコードを間違って見えるようにする。

要するに、変数名の前に（文字列）（Systems Hungarian）を付けるハンガリアン記法は、type役に立たないので良くありません。

作成者が意図したハンガリー語表記法で、変数名の前に変数名を付けますkind（Joelの例：安全な文字列または安全でない文字列を使用）。いわゆるApps Hungarianには用途があり、今でも価値があります。

score 104 · Accepted Answer

ジョエルは間違っています。その理由は次のとおりです。

彼が話しているその「アプリケーション」情報は、型システムでエンコードする必要があります。安全なデータを必要とする関数に安全でないデータを渡さないようにするために、変数名の反転に依存するべきではありません。型エラーにする必要があります。そうすることは不可能です。安全でないデータは、安全でない関数に渡すことができないように、安全でないとマークされた型を持つ必要があります。unsafe から safe に変換するには、ある種のサニタイズ機能による処理が必要です。

ジョエルが「種類」と呼んでいるものの多くは種類ではありません。実際、それらはタイプです。

ただし、ほとんどの言語に欠けているのは、これらの種類の区別を強制するのに十分な表現力を持つ型システムです。たとえば、C に一種の「強力な typedef」 (typedef 名には基本型のすべての操作が含まれるが、変換できない) がある場合、これらの問題の多くは解消されます。たとえば、std::string に変換できない (したがって、オーバーロードの解決などに参加できる)strong typedef std::string unsafe_string;新しい型を導入するために、ばかげたプレフィックスは必要ありません。unsafe_string

したがって、ハンガリー語は型ではないものを指すという中心的な主張は間違っています。型情報に使用されています。確かに、従来の C 型情報よりも豊富な型情報。オブジェクトの目的を示すために、ある種のセマンティックな詳細をエンコードするのは型情報です。しかし、それは依然として型情報であり、適切な解決策は常にそれを型システムにエンコードすることでした。それを型システムにエンコードすることは、ルールの適切な検証と適用を実現する最良の方法です。変数名は単にマスタードをカットしません。

つまり、「間違ったコードを開発者に間違ったように見せる」ことが目的であってはなりません。「間違ったコードをコンパイラに間違ったように見せる」べきです。

score 46 · Accepted Answer

ソースコードがかなり乱雑になっていると思います。

また、強く型付けされた言語ではあまり得られません。何らかの形式の型の不一致の不正行為を行うと、コンパイラがそのことを通知します。

score 28 · Accepted Answer

ハンガリー語表記は、ユーザー定義型のない言語でのみ意味があります。現代の機能言語またはオブジェクト指向言語では、値の「種類」に関する情報を、変数名ではなくデータ型またはクラスにエンコードします。

いくつかの回答はJoels の記事を参照しています。ただし、彼の例は VBScript を使用していることに注意してください。これは、(少なくとも長い間) ユーザー定義のクラスをサポートしていませんでした。ユーザー定義型を使用する言語では、HtmlEncodedString 型を作成して同じ問題を解決し、Write メソッドがそれのみを受け入れるようにします。静的に型付けされた言語では、コンパイラはエンコーディングエラーをキャッチします。動的に型付けされた言語では、実行時例外が発生しますが、いずれにしても、エンコードされていない文字列の書き込みから保護されます。ハンガリー語の表記法は、プログラマーを人間の型チェック担当者に変えるだけであり、通常はソフトウェアで処理する方が適切な種類の仕事です。

Joel は「システムハンガリー語」と「アプリハンガリー語」を区別しています。「システムハンガリー語」は int や float などの組み込み型をエンコードし、「アプリハンガリー語」は高レベルのメタ情報である「種類」をエンコードします。マシンタイプを超えた変数について、オブジェクト指向または最新の関数型言語では、ユーザー定義型を作成できるため、この意味で型と「種類」の間に区別はありません - どちらも型システムで表すことができます - そして「アプリ」ハンガリー語は、「システム」ハンガリー語と同じくらい冗長です。

したがって、あなたの質問に答えるために:システムハンガリアンは、int 変数に float 値を代入するとシステムがクラッシュするなど、安全でなく、型付けが弱い言語でのみ役立ちます。ハンガリー語表記法は、型チェックをまったく行わないかなり低レベルの言語であるBCPLで使用するために 60 年代に特に発明されました。今日一般的に使用されている言語にこの問題があるとは思いませんが、この表記法は一種のカーゴカルトプログラミングとして存続しました。

従来の VBScript や初期バージョンの VB など、ユーザー定義型のない言語を使用している場合、ハンガリー語アプリは意味があります。おそらく、Perl と PHP の初期バージョンも同様です。繰り返しますが、現代語でそれを使用することは、純粋なカーゴカルトです.

他の言語では、ハンガリー語は醜く、冗長で、壊れやすいものです。型システムからすでに知られている情報を繰り返すので、自分自身を繰り返すべきではありません。変数には、型のこの特定のインスタンスの意図を説明するわかりやすい名前を使用してください。型システムを使用して、変数の「種類」または「クラス」に関する不変条件とメタ情報をエンコードします。種類。

Joels の記事の一般的なポイント - 間違ったコードが間違っているように見えること - は非常に優れた原則です。ただし、バグに対するさらに優れた保護は、可能な限り、間違ったコードをコンパイラによって自動的に検出されるようにすることです。

score 27 · Accepted Answer

私はすべてのプロジェクトで常にハンガリー語表記法を使用しています。何百もの異なる識別子名を扱っているとき、これは本当に役に立ちます。

たとえば、文字列を必要とする関数を呼び出すときに、's' と入力してコントロールスペースを押すと、IDE は 's' で始まる変数名を正確に表示します。

もう 1 つの利点は、unsigned の前に u を、signed int の前に i を付けると、潜在的に危険な方法で signed と unsigned を混在させている場所がすぐにわかります。

巨大な 75000 行のコードベースで、ローカル変数にそのクラスの既存のメンバー変数と同じ名前を付けたことが原因で (私や他の人によっても) バグが発生した回数を思い出すことはできません。それ以来、私は常にメンバーの前に「m_」を付けています

味と経験の問題です。試してみるまでノックしないでください。

score 22 · Accepted Answer

この情報を含める最大の理由を忘れています。プログラマーであるあなたとは何の関係もありません。それは、あなたが会社を辞めてから 2、3 年後にそのようなものを読まなければならない人に関係しています。

はい、IDE は型をすばやく識別します。ただし、「ビジネスルール」コードの長いバッチを読んでいるときに、変数ごとに一時停止してその型を調べる必要がないのは便利です。strUserID、intProduct、または guiProductID などを見ると、「準備」時間がはるかに簡単になります。

私は、MS が命名規則のいくつかを使いすぎたことに同意します。

命名規則に固執する限り、命名規則は良いことです。私は、「キャメルケーシング」（前の仕事で呼び出されたように）をプッシュする、非常に多くの同様の名前の変数の定義を常に見直す必要がある古いコードを十分に調べてきました。現在、私は VBScript を使用して完全にアンコメントされた何千行もの従来の ASP コードを扱う仕事をしています。

score 10 · Accepted Answer

各変数名の先頭にある不可解な文字を追加する必要はなく、変数名自体が十分に説明的ではないことを示しています。ほとんどの言語はとにかく宣言時に変数型を必要とするので、情報はすでに利用可能です。

メンテナンス中に変数タイプを変更する必要がある場合もあります。例：「uint_16u16foo」として宣言された変数を64ビットの符号なしにする必要がある場合、次の2つのいずれかが発生します。

各変数名を調べて変更します（同じ名前の無関係な変数をホースでつながないように注意してください）、または
タイプを変更するだけで、名前は変更しないでください。混乱を招くだけです。

score 9 · Accepted Answer

Joel Spolskyは、これについて良いブログ投稿を書きました。 http://www.joelonsoftware.com/articles/Wrong.html 基本的に、適切なIDEが、覚えていない場合に変数を入力するように指示するときに、コードを読みにくくしないようにします。また、コードを十分にコンパートメント化すると、3ページ上でどの変数が宣言されたかを覚えておく必要がなくなります。

score 9 · Accepted Answer

最近のタイプよりもスコープの方が重要ではありません。

* l for local
* a for argument
* m for member
* g for global
* etc

タイプを変更したために古いコードをリファクタリングし、シンボルを検索して置き換えるという最新の手法では、コンパイラはタイプの変更をキャッチしますが、スコープの誤った使用をキャッチしないことがよくあります。ここでは、適切な命名規則が役立ちます。

score 8 · Accepted Answer

ハンガリー語表記を正しく使用しない理由はありません。人気がないのは、特に Windows API でのハンガリー語表記の誤用に対する長年の反発によるものです。

DOS 用の IDE に似たものが存在する前の古き良き時代 (Windows でコンパイラを実行するのに十分な空きメモリがなかったため、開発は DOS で行われた可能性があります) には、何の助けも得られませんでした。変数名の上にマウスを置きます。(マウスを持っていると仮定します。) 対処しなければならなかったのは、すべてが 16 ビット int (WORD) または 32 ビット int (LONG WORD) として渡されるイベントコールバック関数でした。次に、これらのパラメーターを特定のイベントタイプの適切なタイプにキャストする必要がありました。実際、API の多くは事実上型がありませんでした。

その結果、次のようなパラメーター名を持つ API が生成されます。

LRESULT CALLBACK WindowProc(HWND hwnd,
                            UINT uMsg,
                            WPARAM wParam,
                            LPARAM lParam);

wParam と lParam という名前は、かなりひどいものですが、param1 と param2 という名前よりも悪くはないことに注意してください。

さらに悪いことに、Window 3.0/3.1 には、near と far の 2 種類のポインターがありました。したがって、たとえば、メモリ管理関数 LocalLock からの戻り値は PVOID でしたが、GlobalLock からの戻り値は LPVOID (長い場合は「L」) でした。その後、そのひどい表記法が拡張され、単純にmallocされた文字列と区別するために、長いポインター文字列の前に lpが付けられました。

この種のことに対して反発があったのは当然のことです。

score 6 · Accepted Answer

Pythonプログラマーとして、ハンガリアン記法はかなり速く崩壊します。Pythonでは、何かが文字列であるかどうかは関係ありません。文字列のように機能できるかどうか（つまり、___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が便利です。

私の見解では、ハンガリアン記法はヒルのようなものです。過去には便利だったかもしれませんし、少なくとも便利に見えたかもしれませんが、最近では、多くのメリットがなく、余分なタイピングが多くなっています。

score 6 · Accepted Answer

ハンガリアン記法は、開発者が特定の変数がどのように使用されているかをすばやく思い出せるため、コンパイル時の型チェックがない言語で役立ちます。パフォーマンスや動作には何の影響もありません。これはコードの可読性を向上させることになっており、ほとんどの場合、好みとコーディングスタイルの問題です。このため、多くの開発者から批判されています。誰もが脳内で同じ配線をしているわけではありません。

コンパイル時の型チェック言語の場合、ほとんど役に立ちません。数行上にスクロールすると、宣言が表示され、型が表示されます。グローバル変数またはコードブロックが複数の画面にまたがっている場合は、設計と再利用性に重大な問題があります。したがって、批判の1つは、ハンガリアン記法により、開発者が悪いデザインを持ち、それを簡単に回避できるということです。これはおそらく嫌われる理由の1つです。

一方、コンパイル時の型チェック言語でさえ、ハンガリアン記法（win32 APIのvoidポインタまたはHANDLE ）の恩恵を受ける場合があります。これらは実際のデータ型を曖昧にし、そこでハンガリアン記法を使用するメリットがあるかもしれません。ただし、ビルド時にデータの種類を知ることができる場合は、適切なデータ型を使用しないでください。

一般に、ハンガリアン記法を使用しないという難しい理由はありません。それは、いいね、ポリシー、コーディングスタイルの問題です。

score 5 · Accepted Answer

IDEはその有用な情報を伝える必要があります。ハンガリー語は、IDEがそれほど進んでいないときに、ある種の（全体ではなく、ある種の）意味を成していた可能性があります。

score 4 · Accepted Answer

私はいつも、適切な場所に1つか2つの接頭辞を付けても問題はないと思っていました。IEnumerableのように、「これはインターフェイスです。特定の動作を当てにしないでください」などの便利なものを伝えることができれば、そうすべきだと思います。コメントは、1文字または2文字の記号以上のものを乱雑にする可能性があります。

score 4 · Accepted Answer

それは信じられないほど冗長であり、ほとんどの最新のIDEは役に立たず、タイプを明確にするのに優れています。

さらに、私にとっては、intI、strUserNameなどを見るのは面倒です:)

score 4 · Accepted Answer

有用な情報が伝えられていると感じたら、それを入手可能な場所に置いてはいけないのはなぜですか。

では、他の誰かの考えを誰が気にするのでしょうか。便利な場合は、表記を使用してください。

score 4 · Accepted Answer

私の経験では、それは悪い理由です：

1-変数の型を変更する必要がある場合（つまり、32ビット整数を64ビット整数に拡張する必要がある場合）、すべてのコードを壊します。

2-型がすでに宣言に含まれているか、最初から実際の型がそれほど重要ではない動的言語を使用しているため、これは役に立たない情報です。

さらに、ジェネリックプログラミングを受け入れる言語（つまり、関数を作成するときに一部の変数の型が決定されない関数）または動的型付けシステム（つまり、コンパイル時に型が決定されない場合）では、どのように名前を付けますか？変数？そして、ほとんどの現代言語は、たとえ制限された形式であっても、どちらか一方をサポートします。

score 4 · Accepted Answer

Joelの記事は素晴らしいですが、1つの主要な点が省略されているようです。

ハンガリー語は、特定の「アイデア」（種類+識別子名）をコードベース全体で一意またはほぼ一意にします-非常に大きなコードベースでも。

これは、コードの保守にとって非常に大きなことです。これは、古き良き1行のテキスト検索（grep、findstr、'すべてのファイルで検索'）を使用して、その'アイデア'のすべての言及を見つけることができることを意味します。

コードの読み方を知っているIDEがあるのに、なぜそれが重要なのでしょうか。彼らはまだそれがあまり得意ではないからです。これは小さなコードベースではわかりにくいですが、大きなコードベースでは明らかです。コメント、XMLファイル、Perlスクリプト、およびソース管理外の場所（ドキュメント、Wiki、バグデータベース）で「idea」が言及されている場合です。

ここでも少し注意する必要があります。たとえば、C / C ++マクロでトークンを貼り付けると、識別子の言及が非表示になる場合があります。このような場合は、コーディング規約を使用して処理できますが、いずれにせよ、コードベース内の少数の識別子にのみ影響を与える傾向があります。

PS型システムとハンガリー語の使用については、両方を使用するのが最善です。コンパイラがあなたのためにそれを捕まえないならば、あなたは間違って見えるために間違ったコードを必要とするだけです。コンパイラにそれをキャッチさせることが不可能な場合がたくさんあります。しかし、それが実行可能な場合-はい、代わりにそれを行ってください！

ただし、実現可能性を検討するときは、タイプを分割することによる悪影響を考慮してください。たとえば、C＃では、「int」を組み込み型ではない型でラップすると、大きな影響があります。したがって、状況によっては意味がありますが、すべてではありません。

score 4 · Accepted Answer

JoelSpolskyのMakingWrongCode Look Wrongで、彼は、誰もがハンガリー語表記法（彼はSystems Hungarianと呼んでいます）と考えているものは、実際に意図されていたもの（彼はApps Hungarianと呼んでいます）ではないと説明しています。このディスカッションを表示するには、[ I'mHungary]の見出しまで下にスクロールします。

基本的に、SystemsHungarianは無価値です。それはあなたのコンパイラやIDEがあなたに言うのと同じことをあなたに伝えるだけです。

Apps Hungarianは、変数が何を意味するのかを教えてくれ、実際に役立つ可能性があります。

score 4 · Accepted Answer

ハンガリアン記法の利点を暴く

変数を区別する方法を提供します。

タイプが1つの値を別の値から区別するすべてである場合、それは1つのタイプから別のタイプへの変換のみに使用できます。タイプ間で変換されているのと同じ値がある場合は、変換専用の関数でこれを実行する必要がある可能性があります。（ハンガリアンVB6の残り物は、JSONオブジェクトを逆シリアル化する方法を理解できなかった、またはnull許容型を宣言または使用する方法を適切に理解できなかったという理由だけで、すべてのメソッドパラメーターで文字列を使用するのを見てきました。）ハンガリー語の接頭辞であり、一方から他方への変換ではない場合は、それらを使用して意図を詳しく説明する必要があります。

コードが読みやすくなります。

ハンガリアン記法は、変数名で人々を怠惰にすることを発見しました。彼らはそれを区別する何かを持っており、彼らはその目的を詳しく説明する必要はないと感じています。これは、ハンガリー語の表記コードと最新のコードでよく見られるものです。sSQLとgroupSelectSql（または、以前の開発者によって導入されたORMを使用することになっているため、通常はsSQLはまったくありません。）、sValueとformCollectionValue（または、通常はsValueもありません。これは、MVCにあり、モデルバインディング機能を使用する必要があるためです）、sTypeとpublishSourceなどです。

読みやすさはありえません。ハンガリーのVB6の残り物から、他のすべての人を合わせたよりも多くのsTemp1、sTemp2...sTempNが表示されます。

エラーを防ぎます。

これは、2番目の理由によるものですが、これは誤りです。

score 4 · Accepted Answer

コントロールのリストが IDE のアルファベット順のプルダウンリストに表示される場合、これはフォーム上のコントロールに名前を付けるための便利な規則 (btnOK、txtLastName など) です。

score 4 · Accepted Answer

私は、ASP.NET サーバーコントロールのみでハンガリー語表記を使用する傾向があります。そうしないと、どのコントロールがフォーム上にあるのかを理解するのが難しくなります。

次のコードスニペットをご覧ください。

<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />

誰かがハンガリー語なしでそのコントロール名のセットを持つより良い方法を示すことができれば、私はそれに移りたいと思うでしょう.

score 3 · Accepted Answer

マスターの言葉で：

http://www.joelonsoftware.com/articles/Wrong.html

いつものように、興味深い読書。

抽出物：

「誰かが、どこかで、「型」という言葉を使ったシモニーの論文を読んで、コンパイラが行う型チェックのように、型システムのように、クラスのように型を意味すると思った。彼は非常に注意深く説明した。彼が「タイプ」という言葉で意味したこととまったく同じですが、それは役に立ちませんでした。被害は発生しました。」

「しかし、Apps Hungarianには、コード内のコロケーションが増え、コードの読み取り、書き込み、デバッグ、保守が容易になり、最も重要なこととして、間違ったコードが間違って見えるようになるという点で、依然として多大な価値があります。」

Joel On Softwareを読む前に、時間を取ってください。:)

score 3 · Accepted Answer

いくつかの理由：

最新の IDE では、マウスを変数の上に置くだけで変数の型が表示されます。
ほとんどの型名はかなり長い ( HttpClientRequestProviderと考えてください) ため、プレフィックスとして適切に使用できます。
型情報には正しい情報が含まれていません。変数の目的を概説するのではなく、変数宣言を言い換えているだけです ( myIntegerとpageSizeを考えてください)。

score 2 · Accepted Answer

誰もがそれに激しく反対しているとは思いません。静的型のない言語では、これは非常に便利です。まだタイプに含まれていない情報を提供するために使用される場合は、間違いなくそれを好みます。Cの場合と同様に、char * szNameは、変数がnullで終了する文字列を参照することを示します（char *には暗黙的ではありません）。もちろん、typedefも役立ちます。

Joelは、ハンガリー語を使用して変数がHTMLエンコードされているかどうかを判断するための優れた記事を掲載しました。

http://www.joelonsoftware.com/articles/Wrong.html

とにかく、私はハンガリー語が私がすでに知っている情報を伝えるために使用されるとき、それを嫌う傾向があります。

score 2 · Accepted Answer

もちろん、プログラマーの99％が何かに同意するとき、何かが間違っています。彼らがここで同意する理由は、彼らのほとんどがハンガリアン記法を正しく使用したことがないからです。

詳細な議論については、私がこの件に関して行ったブログ投稿を参照してください。

http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html

score 2 · Accepted Answer

私がコーディングを始めたのは、ハンガリー語表記法が発明された頃とほぼ同じ頃で、それが嫌いなプロジェクトで初めて使用を余儀なくされたときです。

しばらくして、それが適切に行われたときに実際に役立つことに気づき、最近はそれが大好きです.

しかし、すべての良いことと同様に、それを学び、理解する必要があり、適切に行うには時間がかかります.

score 1 · Accepted Answer

ハンガリアン記法は、特にMicrosoftによって悪用され、変数名よりも長いプレフィックスが使用され、特にタイプ（Win16ではタイプ/サイズが異なる悪名高いlparam / wparam、Win32では同一）を変更した場合に非常に堅固であることを示しています。）。

したがって、この悪用とM $による使用の両方のために、それは役に立たないものとして置かれました。

私の仕事ではJavaでコーディングしていますが、創設者はMFCの世界から来たので、同様のコードスタイルを使用します（中括弧を揃えて、これが好きです！、メソッド名に大文字、それに慣れています、クラスメンバー（フィールド）にm_のようなプレフィックスを付けます）、静的メンバーへのs_など）。

そして彼らは、すべての変数にそのタイプを示すプレフィックスを付ける必要があると述べました（たとえば、BufferedReaderの名前はbrDataです）。タイプは変更される可能性がありますが、名前が続かないか、コーダーがこれらのプレフィックスの使用に一貫性がないため、これは悪い考えであることが示されました（aBuffer、theProxyなども表示されます！）。

個人的には、有用だと思ういくつかのプレフィックスを選択しました。最も重要なのは、ブール変数のプレフィックスとしてbです。これは、次のような構文を許可する唯一if (bVar)のプレフィックスであるためです（trueまたはfalseへの一部の値の自動キャストは使用しません）。Cでコーディングしたとき、mallocで割り当てられた変数にプレフィックスを使用しました。これは、後で解放する必要があることを思い出させるためです。等。

したがって、基本的に、私はこの表記法全体を拒否するのではなく、自分のニーズに合っていると思われるものを採用しました。
そしてもちろん、いくつかのプロジェクト（仕事、オープンソース）に貢献するとき、私はただ慣習をそのまま使用します！

score 1 · Accepted Answer

美的側面のすべてが誇大宣伝されていると思います。それが最も重要なことである場合、私たちは自分たちを開発者ではなく、グラフィックデザイナーと呼びます。

重要な部分の 1 つは、オブジェクトの役割ではなく、オブジェクトの役割を説明することだと思います。別の文脈では、最も重要なことに、あなたは人間ではないからです。

リファクタリングの目的でも、これは非常に重要です。

public string stringUniqueKey = "ABC-12345";

文字列の代わりに GUID を使用することにした場合、すべての参照コードをリファクタリングした後、変数名はばかげているように見えます。

または：

public int intAge = 20;

これをフロートに変更すると、同じ問題が発生します。等々。

score 0 · Accepted Answer

リンクが見つかりませんが、ハンガリアン記法を避けることでプログラミングスタイルが向上することをどこかで読んだことを覚えています（私は同意します）。

プログラムのステートメントをプログラムするときは、メソッドを呼び出す前に「このオブジェクトのタイプ」を考えるのではなく、「オブジェクトで何をしたいのか」、「どのメッセージを送信するのか」を考える必要があります。 "。

説明するのは漠然とした概念のようなものですが、うまくいくと思います。

たとえば、顧客名が変数customerNameに格納されている場合、それが文字列であるか他のクラスであるかを気にする必要はありません。このオブジェクトから何が欲しいかを考えることがより重要です。print（）、getFirstName（）、getLastName（）、convertToString（）などにしますか。Stringクラスのインスタンスにして、当然のことと見なすと、すべてを構築する必要があるため、自分自身とデザインを制限します。コードの他の場所で必要な他のロジック。

score 0 · Accepted Answer

彼らは巨大な目障りです
IDEは、変数の型について知る必要があるすべてを教えてくれるはずです。
良い名前（HNが邪魔になる）は、変数について知っておく必要のある他のすべてのことをあなたに伝える必要があります。

score 0 · Accepted Answer

メンバー変数にはどのようなプレフィックスを使用しますか?も参照してください。

score 0 · Accepted Answer

何年もの間、私はプログラミングでハンガリー語表記法を使用していました。視覚的な混乱と、データ型を変更したときに接頭辞を変更するというタスクを除けば、誰も私を納得させることができませんでした。最近まで、既存の C# アセンブリと VB.NET アセンブリを同じソリューションに結合する必要がありました。

結果: "fltSomeVariable" を "sngSomeVariable" メソッドパラメータに渡す必要がありました。C# と VB.NET の両方でプログラミングを行っている者としても、不意を突かれ、一瞬立ち止まってしまいました。(C# と VB.NET では、float と single のように、同じデータ型を表すのに異なる名前を使用することがあります。)

ここで考えてみてください: 多くの言語から呼び出し可能な COM コンポーネントを作成するとどうなるでしょうか? VB.NET と C# の「変換」は、.NET プログラマーにとって簡単でした。しかし、C++ や Java で開発する人はどうでしょうか? 「dwSomeVariable」は、C++ に慣れていない .NET 開発者にとって何か意味がありますか?

score 0 · Accepted Answer

ハンガリー語が悪いのは、型情報と引き換えに変数名から貴重な文字を取り除いているからです。

まず第一に、強く型付けされた言語では、本当にばかげたことをするとコンパイラが警告します。

第二に、モジュール化された優れたコードを信じていて、1 つの関数であまり多くの作業を行わない場合は、変数が使用されているコードのすぐ上で変数が宣言されている可能性があります (そのため、そこに型があります)。

第三に、すべてのポインタに p のプレフィックスを付け、すべてのクラスに C のプレフィックスを付けると、最新の IDE のインテリセンス機能が台無しになります (入力したクラス名を入力するとすぐに推測する機能を知っています)。 Enter キーを押すだけで完了しますか? まあ、すべてのクラスの前に C を付けると、常に少なくとも 1 文字余分に入力する必要があります)...

score 0 · Accepted Answer

言われずに変数の型がわからない場合は、とにかくそれをいじる必要はありません。

タイプもそれほど重要ではないかもしれません。メソッドが何をするかを知っていれば、変数で何が行われているかを把握でき、プログラムが何をしているかがわかります

あなたがそれを望む時があるかもしれません。型が重要で、宣言が近くにないか、型を簡単に推測できない場合。しかし、それは絶対的なものと見なされるべきではありません

language-agnostic - なぜ「ハンガリアン記法」を使わないのですか？

37 に答える 37

ハンガリアン記法の利点を暴く

Related

Reference