私はすべて、プレフィックスがうまく機能していることを支持しています。
（システム）ハンガリー語表記は、接頭辞が取得するほとんどの「不良ラップ」の原因であると思います。
この表記は、強く型付けされた言語、たとえばC ++ "lpsz"では、文字列がnulで終了する文字列への長いポインタであることを示すために、ほとんど意味がありません。 char配列。 "customerName"が文字列であることを知るのはそれほど難しくありません。
ただし、変数の使用法を指定するために接頭辞を使用します（本質的には「Appsハンガリー語」ですが、システムハンガリー語との関連が不適切で不公平であるため、ハンガリー語という用語は避けたいと思います）。これは非常に便利な時間節約であり、バグを減らすアプローチ。
私が使う：
- メンバーのm
- 定数/読み取り専用のc
- ポインターのp（およびポインターへのポインターのpp）
- v揮発性
- 静的の場合
- インデックスとイテレータのi
- イベントのe
タイプを明確にしたい場合は、標準のサフィックス（リスト、コンボボックスなど）を使用します。
これにより、プログラマーは変数を表示/使用するたびに変数の使用法を認識できます。間違いなく最も重要なケースは、ポインタの "p"です（使用法が変数から変数->に変更され、ポインタ（NULL、ポインタ演算など）についてはさらに注意する必要があるため）が、他のすべては非常に便利です。
たとえば、1つの関数で同じ変数名を複数の方法で使用できます（ここではC ++の例ですが、多くの言語に同じように適用されます）。
MyClass::MyClass(int numItems)
{
mNumItems = numItems;
for (int iItem = 0; iItem < mNumItems; iItem++)
{
Item *pItem = new Item();
itemList[iItem] = pItem;
}
}
あなたはここで見ることができます：
- メンバーとパラメーターの混同はありません
- インデックス/イテレータとアイテムの間に混乱はありません
- 「カウント」、「インデックス」などの一般的な（あいまいな）名前の多くの落とし穴を回避する、明確に関連する一連の変数（アイテムリスト、ポインタ、インデックス）の使用。
- 接頭辞は、「itemIndex」や「itemPtr」などの代替手段よりもタイピングを減らします（短く、オートコンプリートでよりよく機能します）。
「iName」イテレータのもう1つの優れた点は、間違ったインデックスで配列にインデックスを付けないことです。ループを別のループ内にコピーする場合、ループインデックス変数の1つをリファクタリングする必要はありません。
この非現実的な単純な例を比較してください：
for (int i = 0; i < 100; i++)
for (int j = 0; j < 5; j++)
list[i].score += other[j].score;
（これは読みにくく、多くの場合、「j」が意図されていた場所で「i」が使用されることになります）
と：
for (int iCompany = 0; iCompany < numCompanies; iCompany++)
for (int iUser = 0; iUser < numUsers; iUser++)
companyList[iCompany].score += userList[iUser].score;
（これははるかに読みやすく、索引付けに関するすべての混乱を取り除きます。最新のIDEのオートコンプリートにより、これもすばやく簡単に入力できます）
次の利点は、コードスニペットでコンテキストを理解する必要がないことです。2行のコードをメールまたはドキュメントにコピーできます。そのスニペットを読むと、すべてのメンバー、定数、ポインター、インデックスなどの違いを知ることができます。「ああ、追加する必要はありません。注意してください。 'data'は 'ppData'と呼ばれるため、ポインターへのポインターです。
同じ理由で、コード行を理解するために目を離す必要はありません。'data'がローカル、パラメーター、メンバー、または定数であるかどうかを見つけるためにコードを検索する必要はありません。マウスに手を移動する必要がないので、ポインターを「データ」の上に置いて、ツールチップ（時々表示されない）がポップアップするのを待ちます。そのため、プログラマーは、コードの読み取りと理解を大幅に高速化できます。これは、上下に検索したり待機したりする時間を無駄にしないためです。
（仕事をするために上下に検索するのに時間を費やすと思わない場合は、1年前に作成し、それ以降見ていなかったコードを見つけてください。ファイルを開いて、読んでいない状態で半分ほど下にジャンプします。方法を見るメンバー、パラメーター、ローカルのいずれであるかが分からなくなる前に、この時点から読み取ることができます。次に、別のランダムな場所にジャンプします...これは、他の誰かのコードをシングルステップ実行しているときに、私たちが1日中行うすべてのことです。またはそれらの関数を呼び出す方法を理解しようとする）
接頭辞「m」は、（IMHO）の醜く冗長な「this->」表記、およびそれが保証する不整合も回避します（注意していても、通常は「this-> data」と名前の一貫したスペルを強制するものがないため、同じクラスの「データ」）。
「この」表記は、あいまいさを解決することを目的としていますが、あいまいになる可能性のあるコードを故意に誰かが作成するのはなぜですか？あいまいさは遅かれ早かれバグにつながります。また、一部の言語では、静的メンバーに「this」を使用できないため、コーディングスタイルに「特殊なケース」を導入する必要があります。私はどこにでも適用できる単一の単純なコーディングルールを用意することを好みます-明示的で、明確で、一貫しています。
最後の主な利点は、Intellisenseとオートコンプリートです。イベントを見つけるには、WindowsフォームでIntellisenseを使用してみてください。イベントを見つけるために呼び出す必要のない、何百もの神秘的な基本クラスメソッドをスクロールする必要があります。しかし、すべてのイベントに「e」という接頭辞が付いている場合、それらは自動的に「e」の下のグループにリストされます。したがって、プレフィックスを付けると、インテリセンスリストのメンバー、定数、イベントなどがグループ化され、必要な名前をすばやく簡単に見つけることができます。（通常、メソッドにはスコープ内でアクセス可能な約20〜50の値（ローカル、パラメーター、メンバー、定数、イベント）がある場合があります。ただし、接頭辞を入力した後（ここでインデックスを使用したいので、「i。 .. '）、2-5のオートコンプリートオプションのみが表示されます。
私は怠惰なプログラマーであり、上記の慣例は私に多くの仕事を節約します。すべての変数の使用方法を知っているので、コーディングを高速化でき、ミスを大幅に減らすことができます。
反対意見
では、短所は何ですか？プレフィックスに対する一般的な引数は次のとおりです。
「プレフィックス方式は悪い/悪い」。「m_lpsz」とそのilkはよく考えられておらず、まったく役に立たないことに同意します。そのため、コンテキストに適さないものをコピーするのではなく、要件をサポートするように設計された表記法を使用することをお勧めします。（ジョブに適したツールを使用してください）。
「何かの使用法を変更した場合は、名前を変更する必要があります」。はい、もちろんそうです。それがリファクタリングのすべてであり、IDEがこの作業を迅速かつ簡単に行うためのリファクタリングツールを備えている理由です。でも接頭辞なしで、変数の使用方法を変更すると、ほぼ確実にその名前が意味べき変更します。
「接頭辞は私を混乱させる」。あなたがそれを使用する方法を学ぶまで、すべてのツールと同じように。脳が命名パターンに慣れると、情報が自動的に除外され、接頭辞がなくても問題ありません。しかし、本当に「流暢」になるには、このようなスキームを1〜2週間しっかりと使用する必要があります。そして、多くの人が古いコードを見て、優れた接頭辞スキームなしでどうやって管理したのか疑問に思い始めるときです。
「私はこのことをうまく処理するためにコードを見ることができます」。はい。しかし、コードのどこか他の場所を調べたり、目がすでに集中しているその場で答えが正しい場合は、コードの細部をすべて覚えたりして時間を無駄にする必要はありません。
（一部）その情報は、ツールチップが変数にポップアップするのを待つだけで見つけることができます。はい。サポートされている場合、一部の種類の接頭辞については、コードが正常にコンパイルされると、待機後に説明を読み、接頭辞が即座に伝えた情報を見つけることができます。プレフィックスは、よりシンプルで信頼性が高く、より効率的なアプローチだと思います。
「それはよりタイピングです」。本当に？もう一文字？またはそれは-IDEのオートコンプリートツールを使用すると、各プレフィックス文字によって検索スペースが大幅に狭まるため、入力が少なくなることがよくあります。「e」を押すと、クラスの3つのイベントがインテリセンスにポップアップ表示されます。「c」を押すと、5つの定数がリストされます。
" this->代わりに使えるm"。ええ、そうです。しかし、これは非常に醜く、より冗長な接頭辞です。コンパイラにとってそれはオプションであり、そのためその使用法はしばしば一貫性がないため、それだけが（特にチームで）はるかに大きなリスクを伴います。m一方、簡潔で明確、明示的であり、オプションではないため、それを使用して間違いを犯すことははるかに困難です。