C＃でのハンガリー語表記
C＃を使用する前は、C++が私の主要なプログラミング言語でした。そして、ハンガリー語の記法は私の心の奥深くにあります。
言語に関するC＃の本やその他のガイドラインを読むことなく、C＃でいくつかの小さなプロジェクトを行いました。これらの小さなc＃プロジェクトでは、次のようなものを使用しました
private string m_strExePath;
SOから何かを読むまで：
ハンガリー語表記は使用しないでください。
なぜ？私のC＃コードにm_strExePathまたはm_iNumberがあるのは私だけですか？
Joel Spolskyは、このトピックに関して非常に優れた article を持っています。簡単にまとめると、実際に使用されているハンガリー語の表記には2つのタイプがあるということです。
1つ目は "Systems Hungarian"で、プレフィックスを使用して変数の型を指定します。文字列の「str」のようなもの。特に最近のIDEはとにかくタイプを教えてくれるので、これはほとんど役に立たない情報です。
2つ目は "Apps Hungarian"で、変数のpurposeをプレフィックスで指定します。この最も一般的な例は、メンバー変数を示すために「m_」を使用することです。これは、正しく実行すると非常に役立ちます。
ペストのような「システムハンガリー語」を回避することをお勧めしますが、意味がある場合は「アプリハンガリー語」を必ず使用してください。 Joelの記事を読むことをお勧めします。少し曲がりくねっていますが、私が説明できるよりもずっとよく説明しています。
この記事の最も興味深い部分は、ハンガリー語表記の元の発明者であるCharles Simonyiが「Apps Hungarian」を作成したが、彼の論文がひどく誤って解釈され、その結果「Systems Hungarian」の忌避が作成されたことです。
ユーザーインターフェイスの設計を行うとき、ハンガリー語の表記を維持することは非常に便利です。テキストボックス、ラベル、ドロップダウンリストなどの項目は、すぐに理解しやすく、繰り返しコントロール名を取得することがよくあります。
lblTitle = Label
txtTitle = TextBox
ddlTitle = DropDownList
私にとっては、読みやすく、解析しやすいです。そうでなければ、IDE、特にVisual Studioの進歩により、ハンガリー語の表記は適合しません。
また、Joel on Softwareには、ハンガリー語表記に関連する優れた記事 間違ったコードを間違ったものにする があり、いくつかの良い議論をしていますforハンガリー語表記）。
あなただけではありませんが、比較的珍しいと思います。個人的には、私はハンガリー語の表記法のファンではありません。少なくとも、宣言に既に存在する型情報を単に言い換えるという単純な意味ではそうではありません。 （「真の」ハンガリー語表記のファンは違いを説明します-それはそれほど気になりませんでしたが、私はそれらのポイントを見ることができます。たとえば、長さの単位と重量の単位に共通の接頭辞を使用すれば、誤ってしまうことはありません両方とも整数であっても、長さ変数に重み値を割り当てます。）
ただし、プライベートメンバーの場合は、ほとんど何でも好きなことができます。命名規則がどうあるべきかチームに同意してください。重要な点は、[〜＃〜] api [〜＃〜]を.NETの他の部分と一致させたい場合は、パブリックメンバー（パラメーターを含む）でハンガリー語表記を使用しないことです。 ）。
いいえ、それを行うのはあなただけではありません。ハンガリー語の表記法がC＃で名前を付けるための最良の方法ではないことが一般に受け入れられています（IDEはハンガリー語の表記法が対処しようとした問題を多く処理します）。
any言語では、ハンガリー語の表記はひどい間違いです。 C++でも使用しないでください。変数に名前を付けて、目的がわかるようにします。 IDEはとにかくあなたに与えることができる、そしてそれは変わるかもしれない（そして通常はとにかく無関係）であるタイプ情報を複製するようにそれらに名前を付けないでください。それがint16、32、64のいずれであるかは関係ありません。これはカウンターとして機能するため、カウンターで有効な操作はすべて有効である必要があります。X/ Y座標についても同じ引数です。これらは座標です。フロートかダブルかは関係ありません。値が重量、距離、または速度の単位であるかどうかを知ることは重要です。フロートであるかどうかは関係ありません。）.
実際、ハンガリー語の表記は誤解としてのみ出てきました。発明者はそれが変数の「概念的な」タイプを記述するために使用されることを意図していました（それは座標、インデックス、カウンター、ウィンドウですか？）
そして、彼の説明を読んだ人々は、「タイプ」とは実際のプログラミング言語のタイプ（int、float、ゼロで終わる文字列、charポインタ）を意味すると想定していました
それは決して意図したことではなく、それは恐ろしい考えです。 IDEはより適切に提供できる情報を複製しますが、それは、最初は可能な限り低い抽象化レベルでプログラミングすることを奨励するため、そもそもそれほど重要ではありません。
なぜ？私は
m_strExePathまたはm_iNumberC＃コードで？
残念ながら、そうではありません。教えてください、もしそれがexePathだとしたらではなかった文字列でしょうか？コードの読者が文字列であることを知る必要があるのはなぜですか？それが実行可能ファイルへのパスであることを知るには十分ではありませんか？ m_iNumberの名前が間違っています。 どれ番号はこれですか？それは何のため？あなたはそれが数字だと二度私に言ったが、私はまだその数字の意味が何であるか知りません。
あなたは確かに唯一の人物ではありませんが、減少傾向にあることを願っています:)
ハンガリー語表記の問題は、命名規則を介して型システムを実装しようとしていることです。これは人間による検証のみを行う型システムであるため、非常に問題があります。プロジェクトのすべての人間は、同じ一連の標準に同意し、厳格なコードレビューを行い、すべての新しいタイプに適切で正しい接頭辞が割り当てられていることを確認する必要があります。つまり、十分に大きなコードベースとの一貫性を保証することは不可能です。一貫性がない時点で、なぜそれをしているのですか？
さらに、ツールはハンガリー語表記をサポートしていません。表面的にはばかげたコメントのように思えるかもしれませんが、たとえばリファクタリングを検討してください。ハンガリー語の命名規則システムでの各リファクタリングには、接頭辞が確実に維持されるように、一括リネームが必要です。大量の名前変更は、あらゆる種類の微妙なバグの影響を受けます。
名前を使用して型システムを実装する代わりに、型システムに依存します。自動検証とツールのサポートがあります。新しいIDEでは、変数の型（インテリセンス、ホバーのヒントなど）を見つけやすくなり、ハンガリー語表記の本来の欲求を本当に取り除くことができます。
ハンガリー語の表記法の1つの欠点は、開発者がコーディングの初期段階で変数のタイプを頻繁に変更するため、変数の名前も変更する必要があることです。
vSではなくテキストエディターを使用している場合を除きIDEハンガリー語の表記にはほとんど価値がなく、読みやすさを向上させるのではなく妨げになります
ハンガリー語表記の本当の価値は、Cプログラミングと弱く型付けされたポインターの性質にさかのぼります。基本的に、当時、タイプを追跡する最も簡単な方法は、ハンガリー語を使用することでした。
C＃のような言語では、タイプシステムは必要な情報をすべて伝えてくれます。IDEは非常にユーザーフレンドリーな方法でこれを表示するので、ハンガリー語を使用する必要はありません。
それを使わない正当な理由としては、まあかなりあります。まず、C＃では、C++や他の多くの言語で独自のタイプを作成することが多いので、「MyAccountObject」タイプのハンガリー語は何でしょうか。賢明なハンガリー語の表記法を決定できる場合でも、最初の "LPZCSTR"（または何でも）をスキップする必要があるため、実際の変数名は読みにくくなります。さらに重要なのは保守コストですが、リストから始めて別の種類のコレクションに変更した場合はどうなりますか（現時点で私がよく行っているようです）。次に、その型を使用するすべての変数の名前を変更する必要があります。最初からまともな名前を使用していた場合は、これについて心配する必要はありません。
あなたの例では、パスを保持するためのより意味のあるタイプ（例：Path）を作成または使用した場合、m_strExePathをm_pathExePathに変更する必要があります。実際に非常に役立ちます。
現在、ハンガリー語の表記法が表示されているのは、次の2つだけです。
- 先頭にアンダースコアを付けたクラスメンバー変数（例：
_someVar） - WinFormsおよびWebFormsのコントロール名（
btnはボタン、lblはラベルなど）
メンバー変数の先頭のアンダースコアは、しばらくの間私たちと一緒にいるようですが、コントロール名のハンガリー語の人気が衰退することを期待しています。
ほとんどのハンガリー語の表記は、変数が何であるか（ポインタ、またはポインタへのポインタ、またはポインタの内容など）と、それが指すもの（文字列など）を記述しています。
特にアンマネージ/ピンボーク呼び出しがない場合は、C＃でポインターをほとんど使用していません。また、void *を使用するオプションはないため、ハンガリー語で記述する必要はありません。
私（およびC＃の土地にいる他のほとんどの人）が使用するハンガリー語からの残りは、_のように、プライベートフィールドの前に_customersを付けることです。
ハンガリー語の表記法があなたとあなたのチームとあなたの会社の心の奥深くにあるなら、ぜひそれを使ってください。ブログや本から読める限り、これはもはやベストプラクティスとは見なされていません。
VSで変数の上にポインターを置くと、その変数のタイプがわかります。そのため、これらの不可解な変数名を使用する理由はありません。他の言語から来ている人は、コードを保守する必要がある場合があるためです。読みやすさの妨げになります。
ハンガリー語の表記法は、最初の主要な使用法である [〜＃〜] bcpl [〜＃〜] プログラミング言語での使用を発見しました。 BCPLはBefore Cプログラミング言語の略であり、すべてがWordである古くて（1966年に設計された）タイプレス言語です。そのような状況では、ハンガリー語の表記が裸眼の型チェックに役立ちます。
それから何年も経ちました...
これが最新の Linuxカーネルのドキュメント の内容です（太字）：
関数の型を名前にエンコードすると（いわゆるハンガリー語表記）、脳が損傷します-コンパイラは型を知っていて、それらをチェックできます、およびプログラマを混乱させるだけです。
ハンガリー語の表記には2つのタイプがあることに注意してください。
Systems Hungarian notation：プレフィックスはphysicalデータ型をエンコードします。
Appsハンガリー語表記：接頭辞はlogicalデータ型をエンコードします。
コンパイラー機能の進歩による型チェックの冗長性のため、システムハンガリー語表記は推奨されなくなりました。ただし、コンパイラーが論理データ型をチェックしない場合は、引き続きAppsハンガリー語表記を使用できます。経験則として、ハンガリー語の表記は、他の方法では利用できないセマンティクスを記述している場合にのみ有効です。
ある時点で、あなたはプロパティを持っている可能性があります
public string ExecutablePath { ... }
（「Exe」のような略語も避けようとするべきではありません）。その場合、C＃3.0の自動プロパティを使用できるので、ほとんどの場合、あなたの質問はあまり意味がありません。
public string ExecutablePath { get; set; }
これで、バッキングストア変数の名前を考える必要がなくなりました。名前、命名規則についての質問/議論はありません。
明らかに、自動実装されたプロパティが常に適切であるとは限りません。
それは効率についてです。変数に誤った値を割り当てるのに費やされた時間。正確な変数宣言を持つことは、効率を上げることです。読みやすさについてです。それは既存のパターンに従うことについてです。創造性が必要な場合は、ユーザーインターフェイスの設計、システムアーキテクチャを実行してください。あなたのプログラミングの場合、それはあなたのチームメンバーがあなたの仕事を楽にするように設計されるべきです：あなたのものではありません。効率が2％向上すると、毎年余分な週になります。これは40時間の増加です。人間の生産性の向上は、効率を複合することによって実現されます。
私は気にしません、私は常にハンガリー語とパスカル/キャメルケースの組み合わせを使用しています。
データ型ではなく、コントロール用です。 txtNameは一目瞭然だからです。名前が長すぎるNameTextBoxに名前を付ける人もいます。 lblAge、txtName、rdoTrue、cboCities、lstAccountInfo。素晴らしく、迅速かつコンパクト変数については、通常の変数とプロパティのPascalケースです。 「firstName = txtFName.Text」（これを見て、テキストボックスであることがわからない場合は、まじめに）。次に、メソッドにキャメルケースを使用します
public void PrintNames (string fName, string lName)
{
lblFullName.Text=fName + " " + lName;
}
そう、私はハンガリーのケースを使用するので、私を訴えます。それらがそれらの変数が何であるかを知らないと誰も言うことはできません、そして私は変数のタイプまたはそれを制御するためにホバリングする必要なしに本当に素早く見ることができるのが好きです。私が最初にプログラミングを始めたとき、すべての変数にすべて大文字を使用したので、これはステップアップです。また、残念なことに、行の終わりに開始中括弧を置かないでください。対称的です。
C＃のような言語では、CやC++などの言語にはかつてあった変数名の長さの制限の多くが存在せず、IDEは変数の型を決定するための優れたサポートを提供します、ハンガリー語表記は冗長です。
M_szNameなどの名前をthis.nameで置き換えることができるように、コードは自明でなければなりません。そして、m_lblNameはnameLabelなどにすることができます。重要なことは、一貫性があり、読みやすく、保守が容易なコードを作成することです。これは、命名規則の目標であるため、これに基づいて使用する規則を常に決定する必要があります。ハンガリー語の表記は、簡潔すぎる可能性があり、接頭辞の意味に関するある程度の知識が必要であり、言語の一部ではないため、適用が難しく、検出が難しいため、最も読みやすく、保守もしにくいと思います。名前が基になる型と一致しなくなったとき。
代わりに、メンバーのthisを参照し、静的変数のクラス名を参照し、ローカル変数の接頭辞を付けずに、Apps Hungarian（m_のような接頭辞）を置き換えます。また、システムハンガリー語（変数名の変数の型を含む）の代わりに、nameLabel、nameTextBox、count、databaseReferenceなど、変数の目的を説明することを好みます。
場合によります。
メソッド/クラスの変数/オブジェクト名にデータ型の説明を追加するのに十分ですか？
System Hungarian Notation> Apps Hungarian Notation
正確なデータ型とサイズを処理するグローバル変数または下位APIの多くを含む手続き型言語（Cなど）で設計している場合（C's<stdint.h>40を超えるさまざまなデータ型表記を使用して説明するなど） int）、System Hungarian Notationがより役立ちます。
ただし、多くの最近のプログラマーは、変数名に型情報を追加することは豊富であると考えています。たとえば、多くの最近のIDEには非常に便利なツールがあります（例： Outline Eclipse、- Symbol Navigator of Xcode、 Visual AssistX of Visual Studioなど）。 System Hungarian Notationは、タイプ情報がIDEのツールとしてすぐに利用できないときに、プログラミング（FORTRAN、C99など）の初期の段階で広く使用されていました。
システムハンガリー語表記<アプリハンガリー語表記
上位レベルのクラスまたはメソッド（C＃アプリケーションのユーザー定義のドライバークラス/メソッドなど）で作業している場合、単純なデータ型を記述するだけでは変数/オブジェクトを説明するには不十分な場合があります。したがって、ここではApps Hungarian Notationを使用します。
たとえば、メソッドの目的が実行可能パスを取得し、見つからない場合にエラーメッセージを表示することである場合、それがstringのタイプであることに注意するのではなく、変数/プログラマーが変数/オブジェクトの目的をよりよく理解するためのオブジェクト：
private string mPathExe;
private string msgNotFound;