私たち全員がこれを見ました：
private String mName;
これは私のためです。
私はそう言った-それは私のせいです。
このトピックは何度も登場しますが
、redditの
議論から、この表記法がどこから来たのか、それがどの程度誤解されているのかについては説明しなかったことを思い出しました。 したがって、この機会を利用していくつかのことを明確にしたいと思います。これは2つの部分で行います。
- どのようにm記法が生まれたのか。
- おそらくハンガリー語の表記法が理解できないのでしょう。
M表記
私はAndroidに取り組んでいる最初のエンジニアの1人であり、Android API（私たち、Androidチーム）とカスタムコードのスタイルガイドの開発を任されました。 当時、私たちにはJava開発者とJavaコードがほとんどいなかったため、大量のコードが登場する前にガイドを作成することが非常に重要でした。
フィールドの定義に関しては、少し偏見があります。 その時点で、私はすでにかなりの量のJava、Windows、およびC ++コードを作成しており、フィールドに特定の構文を使用すると非常に役立つことがわかりました。 Microsoftはこれにm_を使用しますが、C ++では一般的に先頭にアンダースコア（_nameなど）が使用されます。 Javaコードを書き始めて以来、私は常にJavaがこの規約から逸脱しているという事実に悩まされてきました。
しかし、私の仕事は、Javaのスタイルガイドを作成することでした。したがって、Androidでの作業初日からの目標の1つである、Javaプログラマーが非常に快適に感じる開発プラットフォームを作成することです。
だから私は偏見を捨てて、SunとGoogleの内部スタイルガイドを少し勉強しました。私は自分のAndroidガイドを思いつきました。これは、これら2つのガイドが提供するものの99％でしたが、わずかな変更がいくつかありました。
私が覚えている違いの1つは、中括弧に関連していました。 両方のスタイルガイドでは、すべてにブレースを使用する必要がありますが、継続するステートメントが同じ行に収まる場合、例外をスローしました。 この例外の背後にある考え方は、Androidの一般的なログイディオムを考慮することです。
if (Log.DEBUG) Log.d(tag, "Logging");
この例外がなければ、ロギングは多くの画面スペースを占有しますが、これは誰もが同意したことですが、望ましくありません。
したがって、これはスタイルガイドの最初のバージョンであり、フィールドプレフィックスの要件は含まれていませんでした。
ガイドをチームに送りましたが、驚いたことに、フィールドの構文を提供していなかったため、誰もそれを好きではありませんでした。 誰もが、フィールドは標準化されるべきであると信じていました、そして、彼らはそのような規則を持たないリーダーシップに同意しません。
そこで、私は自分の図面に戻り、いくつかの標準化オプションを検討しました。
上記のように_nameとm_nameを考慮しましたが、アンダースコアがJava標準から大きく逸脱しているため、それらを拒否しました。 私は他のいくつかのよりエキゾチックな表記に出くわしました（たとえば、「インスタンス変数」に「iv」プレフィックスを使用します）が、最終的にそれらすべてを拒否しました。 私が考えたことに関係なく、接頭辞「m」は私の頭の中で最も合理的で最もボリュームのないものとしてスピンしました。
それでは、明らかな解決策は何でしたか？ 「m」を取り、下線を削除して、キャメルケースを使用します。 したがって、mNameが生まれました。
この提案はチームに受け入れられ、その後正式に指定されました。
あなたはおそらくハンガリー語の表記を理解していないでしょう
ハンガリー記法（HN）について議論があるときはいつでも、ほとんどの人は、メタデータを識別子に追加するたびに自動的にHNであると考えるように見えることに気付きます。 しかし、HNの基本概念と、Simonyiがこの指定を思いついたときに入れた非常に思慮深いデザインを無視しています。
まず、識別子名に追加できるさまざまなメタデータがあり、それらはすべて異なるカテゴリに属します。 ここに私が現時点で定義したカテゴリーがあります（もっとあるかもしれません）：
それらを一つずつ見てみましょう。
タイプ情報
これはおそらく、フィールドメタデータの最も一般的な使用方法です。フィールドの名前を使用して、タイプを名前で認識できるようにします。 これは、Win32 / 64コード全体で使用されます。ここでは、lpsz_nameなどの名前が「ゼロターミネータを使用した文字列へのロングポインタ」を意味します。 この表記法は非常に冗長で読みにくいように見えますが、実際には頭の中でWindowsプログラマーによってほぼ瞬時に解釈され、追加された情報は、主に多くの非常に動的な性質のために、Windowsシステムの腸で発生する可能性のある多くの不明瞭なエラーをデバッグするのに非常に役立ちますそのAPIとCおよびC ++への大きな依存関係。
可視性情報
これはAndroidが使用するものです。メタデータを使用して、処理している変数のタイプ（フィールド、ローカル、または関数パラメーター）を示します。 フィールドは実際に変数の最も重要な側面であることがすぐに明らかになったので、ローカル変数と関数パラメーターを区別するためのさらなる規約は必要ないと判断しました。 繰り返しますが、このメタデータは変数のタイプとは関係がないことに注意してください。
意味情報
これは、実際、メタデータで最も使用されていない情報ですが、おそらく最も有用です。 このような区別は、同一または類似のタイプの変数、または同一または類似の領域に適用されますが、異なるセマンティクスに属します。
この規則は、類似したタイプの変数を区別する必要があるが、異なる目的に使用される場合に使用できます。 ほとんどの場合、理にかなった名前で目標に到達できますが、メタデータが唯一の方法である場合もあります。 たとえば、ユーザーが名前を入力できるグラフィカルインターフェイスを開発している場合、「名前」と呼ばれるいくつかの表示オプションを使用できます。テキストの編集（「textName」）、テキストビュー（「tvName」）、確認またはキャンセルのボタン（「 okName "、" cancelName "など...）。
そのような例では、これらのすべての識別子が機能（メタデータ）を区別するときに、同じ操作（名前編集）に関連していることを明確に示すことが重要です。
ハンガリー語の表記についてより正確な考えが得られることを願っています。このトピックに関するJoel Spolsey
の記事
「Make wrong code look wrong」を読むことを強くお勧めします。
それでは、ハンガリー記法についてどう思いますか？
まず第一に、「ハンガリー語表記」という用語は曖昧すぎるので、使用をやめる必要があると思います。 この質問をするとき、私は通常、上記の3つのオプションのどれについて話しているかを明確にするように人々に依頼します（そしてほとんどの場合、彼らは確信がなく、それについて考える時間が必要です）。
「識別子メタデータ」という用語を使用して、単純な識別子名に情報を追加するという一般的な考え方を説明しています。 そして、一般的に、このアプローチはこれらの各ケースで利点があると思います。 デフォルトで常にどこでも使用されるべきではないと思いますが、特に上記で説明したGUIの例では、間違いなく便利です。 私は定期的にそのような例を満たし、このタイプのコードに識別子メタデータを使用しないため、コードの読み取り（作成者と将来の読者の両方）と保守がより難しくなります。
「今日、IDEはこれらすべての識別子を色で区別できるので、これを自分で行う必要がなくなりました」という議論にも同意しません。 この引数は、次の2つの理由で誤りです。
- 多くの場合、コードはIDEの外部で読み取られます（皮肉なことに、redditの議論のスクリーンショットから始まりますが、これは強調表示されていません）。 ブラウザー、ターミナル、diff utils、gitツールなどでコードを読みます。ほとんどの場合、コード分析を簡単にするためのハイライトがないため、このような場合に識別子メタデータを使用すると役立ちます。
- IDEでのバックライトは、たとえば上記のグラフィカルインターフェイスなどのあいまいなケースの理解には役立ちません。 開発者は、IDEが認識できる以上にコードについて詳しく知っている場合があり、識別子メタデータを追加することが唯一の妥当な選択です。
識別子のメタデータは決して使用されるべきではない、または常に使用されるべきだと言う人の話を聞いてはいけません。 このタイプのネーミングは開発者の技術の単なるツールであり、識別子にメタデータを追加する時期を判断するのは比較的簡単な常識です。
最後に、この問題に対する暴力的な反応をよく見ます。 私がコードを書いた30年間に、新しいスタイルガイド用のコードを数日間書いた後、あなたは単に気づくのをやめて、完全にそれに従うことに気付きました。 2つのスペースを含むインデントで記述されていないコードを許容できない場合があり、4つのスペースを含むプロジェクトに取り組んでから数か月後、私は反対を感じました。 命名規則でも同じことが起こります。 作業しているコードベース全体に規則が適用される場合、何にでも慣れます。