c# - 可変接頭辞（「ハンガリアン記法」）はもう本当に必要ですか？

Question

C＃は強く型付けされているので、本当に変数にプレフィックスを付ける必要がありますか？

例えば

iUserAge
iCounter
strUsername

以前はプレフィックスを付けていましたが、今後は何のメリットもありません。

score 49 · Accepted Answer

可変プレフィックス（ハンガリー語）は本当にもう必要ですか？

いいえ！

実際、Microsoft独自のスタイルガイドライン（慣習が始まった場所）は現在、これに反対することを推奨しています。特に、次のテキストを含む一般的な命名規則のセクションを参照してください（太字で、それ以下ではありません）。

ハンガリアン記法は使用しないでください。

もちろん、これらのガイドラインは、マイクロソフト以外では拘束力や義務ではありません。ただし、これはプラットフォームベンダーの公開された推奨事項であり、以前のガイドから肯定的な推奨事項を削除するだけでなく、今日では強く表現され強調された否定的な推奨事項になっています。

言い換えれば、それらをもう使用しないでください。

score 30 · Accepted Answer

標準とプレフィックス変数を曲げるのに適していると思われる唯一の場所：

コントロール名: txtWhatever- 私だけではないようです。良い点は、txtName の隣に lblName のようなものを考え出すことができ、NameLabel/NameTextBox 方向に進む必要がないことです。
クラスメンバー変数: _whatever. 私は m_ とまったく接頭辞なしの両方を試しましたが、単純なアンダースコアで終わりました。m_ は入力するのがより難しく、接頭辞がないと混乱することがあります (特にメンテナンス中に、コードを書いている間、すべての人がコードを暗記していることを私は知っています)。

ただし、変数の前にその型を付けるとコードが読みやすくなるという一貫した状況は見つかりませんでした。

編集: Microsoft のガイドラインを読みました。ただし、必要に応じて、コーディングスタイルを進化させたり、「曲げたり」することは許可されていると思います。上で述べたように、試行錯誤の結果、アンダースコアプレフィックスを使用すると便利であることがわかりました。これは、コードのあらゆる場所で this.whatever を使用するよりも確実に優れています。

「進化する」理論のサポート - .NET 1.x で Microsoft がコーディングガイドラインをリリースしたとき、彼らは、定数を含むすべてに Camel ケーシングを使用することを勧めました。私は今、それらが変更されたことを知り、定数またはパブリック読み取り専用フィールドに Pascal ケースを使用することをお勧めします。

さらに、現在、.NET Framework のクラスライブラリでさえ、m_ と _ と s_ でいっぱいです (Reflector で実装を参照してみてください)。つまり、プロジェクト全体で一貫性が保たれている限り、それは開発者次第です。

score 22 · Accepted Answer

ハンガリー語がuCountやpchzNameなどの「型の省略形の接頭辞」を意味する場合、この慣習は悪いことであり、ありがたいことに一般的な使用から消えているように思われます。

ただし、プレフィックスはスコープに非常に役立つと思います。私のスタジオでは、変数のプレフィックスとしてこの規則を使用しています。

i_  // input-only function parameter (most are these)
o_  // output-only function parameter (so a non-const & or * type)
io_ // bidirectional func param
_   // private member var (c#)
m_  // private member var (c++)
s_  // static member var (c++)
g_  // global (rare, typically a singleton accessor macro)

これは非常に便利だと思いました。特にfuncparamプレフィックスは便利です。関数の内部では、その変数がどこから来たのかが一目でわかります。また、通常、変数を変更したり、意味を変更したりする場合は、変数を別の変数にコピーします。

つまり、最新のツールでは、型のプレフィックスは不要です。IDEは、それらを識別してチェックします。ただし、スコープベースのプレフィックスは、読みやすさと明確さのために非常に役立ちます。

Intellisenseのような楽しい副次的な利点もあります。i_ ctrl-spaceと入力して、funcへのすべての入力パラメーターを取得して選択できます。または、g_ ctrl-spaceを使用して、すべてのシングルトンを取得します。時間の節約になります。

score 9 · Accepted Answer

9

いいえ。する必要がありましたか？

于 2008-11-21T16:01:07.447 に答える

score 8 · Accepted Answer

ハンガリアン記法は醜いです。唯一の例外はインターフェースであり、ほとんどの人はそれが許容できると考えています。

Linusはそれをうまく要約しています：「関数の型を名前にエンコードすること（いわゆるハンガリアン記法）は脳に損傷を与えます-コンパイラはとにかく型を知っていてそれらをチェックできます、そしてそれはプログラマーを混乱させるだけです」

score 6 · Accepted Answer

いいえ。ハンガリアン記法は、コードに不要なノイズを追加するだけであり、コンパイラの型チェックでは冗長です。

score 5 · Accepted Answer

はい、Microsoft によって実装されたものではなく、本来の意味でハンガリー語表記が使用された場合。テキストボックスと対応するラベルを lblWhatever、txtWhatever として示している上記の例とよく似ています。型ではなく、変数の使用を定義するために使用します。あなたの番号が moneyTotal であることを知るための情報を提供できます。これは、データ型だけではありません。

しかし、一般的に使用されているように？いいえ。

score 4 · Accepted Answer

接頭辞は、ハンガリアン記法が王だったVB（およびそれ以前！）の時代の残り物です。C＃コミュニティでは、インターフェイスにCapitalのプレフィックスを使用するなどの義務がありますが、これはもはや当てはまりませんI（例ILoadable）。

現在のMicrosoftガイドラインはこちらです。

score 4 · Accepted Answer

ハンガリー語表記法に反対する議論のほとんどは、最新のエディターと IDE が、すべての識別子について知る必要のあるすべての情報を完全に提供できることに言及しています。けっこうだ。

しかし、印刷されたコードはどうでしょうか? 紙でコードレビューやウォークスルーを行っていませんか? トレーニング目的で印刷されたコードを使用していませんか? オンラインヘルプにコードスニペットを使用していませんか? ハンガリー記譜法は、このような場合に非常に価値があります。

私はすべてのコードで (ある種の) ハンガリー語表記法を使い続けています。その不在は醜く、情報が不足していると思います。

score 4 · Accepted Answer

文字列の例のようにデータ型を識別するためにハンガリー語表記は必要なくなりましたが、他の方法で変数の特性を識別するのに引き続き役立ちます。ハンガリー語表記の便利な使い方について説明している良い記事があります: http://www.joelonsoftware.com/articles/Wrong.html

ここに抜粋があります

「シモニーのハンガリー表記法では、すべての変数の前に小文字のタグが付けられ、変数に含まれるものの種類を示していました。

たとえば、変数名が rwCol の場合、rw がプレフィックスです。

シモニーが彼の論文でタイプという言葉を誤って使用し、何世代にもわたるプログラマーが彼の意味を誤解していたため、私は意図的に種類という言葉を使用しています。」

彼はまた、「s」または「u」で始まる文字列を識別する例を使用して、それらが安全に印刷できるかどうかを識別します。間違っていると簡単に識別できます。

score 3 · Accepted Answer

私は個人的にはもうしませんが、スコープの接頭辞を主張する人はまだいます。

私は Microsoft を選び、すべての命名規則に Microsoft の大文字スタイルを使用しています。私の意見では、そのリンクが含まれている「クラスライブラリ開発者向けの設計ガイドライン」セクション全体は、純金です。

さらに、Addison Wesley の「Framework Design Guidelines」という本も大好きです。これらのガイドラインのすべてを、Microsoft チームメンバーからの注釈とともに、彼らが提案しているものを推奨する理由と、それが組織内でどのように採用されているかについて説明します。

score 3 · Accepted Answer

ええと、それに対抗するために、私は言います-それは依存します. 私は個人的には反対ですが、それはあなたのチーム次第です。各チームは、独自の一連のガイドラインを作成する責任を負う必要があります。いわゆるハンガリー記法が含まれていないことを願っていますが、それは実際にはチームの決定であるべきです. スタイルガイドラインを破りたい場合があるかもしれません。

score 3 · Accepted Answer

この質問について私が興味を持っているのは、プレフィックス (つまり、ハンガリー語表記) が導入された言語 (C、次に C++) も厳密に型指定されたという事実です。私が知っている限りでは、それは Microsoft での Pascal の使用によっても行われました。また、ハンガリー人が [;<) にある程度精通していたかもしれない強く型付けされた言語である Mesa でも使用されたようです。

その場合、問題を掘り下げて、(1) 解決に役立つために前置詞が使用された問題と、(2) その問題がどのように解消されたかを検討することは公平です。

私はそれが正確な答えではないことを知っていますが、時代遅れまたは間違った頭の接頭辞を使用することに対する包括的な異議よりも役立つかもしれません.

score 2 · Accepted Answer

絶対にありません。原則として、私はそれが単なるノイズであると信じるようになりました. あなたが独立したコンサルタントであるか、会社に包括的なスタイルガイドがない場合は、IDesignに優れたガイドがあります。ページの右側を見るだけで、C# コーディング標準ドキュメントの最新版を D/L できます。

スティーブ

score 2 · Accepted Answer

データベース（PostgreSQL）でのみ使用します

t_ for table name
v_ for view name
i_ for index name
trig_ for trigger


sp_ for stored procedure name
p_ for parameter    
v_ for variable
c_ for cursor
r_ for record

score 2 · Accepted Answer

コンパイラは変数の型をすばやく簡単にチェックできますが、人間はソースコードの一部をざっと読んでいる間はそうすることができません。したがって、一部の人々 (私のような) は、変数名をもう少し冗長にして、グローバルまたはクラス変数、文字列または int などであることがすぐに認識できるようにすることを好みます。

コンパイラには役立たないかもしれませんが、外国のコードを読むときは、各変数を手動で調べる必要がなくなります...

score 2 · Accepted Answer

ハンガリー語表記は、変数のデータ型を示すために使用されることを意図したものではありませんでした。「str」または「i」を使用して型を暗黙的に定義することを示唆するのは誤解されていました。「型」ではなく、変数の「種類」のみを表示することを意図していました。

したがって、質問に答えるには、現在使用すべきではなく、過去に使用されたこともありません。

リンクされていることは知っていますが、Joel の記事の一番下までスクロールして詳細を確認してください- http://www.joelonsoftware.com/articles/Wrong.html

score 1 · Accepted Answer

私はいつもそれを使用していますが、AccessとExcelでVBAを使用しているためです。

私にとって、CountAllは名前です。intCountAllはこの違いのある名前であり、sintCountAllが静的なpintCountAllプライベートとgintCountAllグローバルを教えてくれるように、名前を追加で記述します（人間専用ではありません）。とても便利です。

コントロール名は、ControlNameの代わりに時間の安全があります。lblControlName、txtControlName、cboControlName、lstControlNameなどがあるので、VBAを使用するときは、lstと入力するだけで、必要な名前がすべて揃っているので、正確な名前を覚えておく必要はありません。これは私に多くの時間を節約しますが、これも主にAccessとExcelのVBAです。

よろしくエミル

score 1 · Accepted Answer

私は常にインスタンスメンバー変数の前にm__を付け、静的メンバー変数の前にs_を付けます。私は、このアプローチを推奨/推奨しないMSの人々からのさまざまな記事に出くわしました。

また、Reflectorを使用して標準の.NETライブラリを調べたときに、 m_プレフィックスに出くわしたこともかなり確信しています...

score 1 · Accepted Answer

いいえ、必要ありません。私はかつてこれに従っていましたが、そのようなコーディング標準に従うことを余儀なくされていました。

また、VS に組み込まれた Intellisense、コード定義ウィンドウ、リファクタリングツール、および CodeRush Express や Refactor Pro などの他のサードパーティプラグインを使用すると、コードを使用しなくても簡単に作業できます。

score 1 · Accepted Answer

適切な規則の概要については、http: //msdn.microsoft.com/en-us/library/ms229002.aspxを参照してください。

それについての本があり、その中で彼らはその慣習のそれぞれの背後にある理由を説明しています. かなり興味深い読み物。

score 1 · Accepted Answer

コード内でデータ型を扱う場合、ハンガリー語表記を使用する理由がわかりません。

しかし、テキストボックス、ドロップダウンリスト、グリッドなど、一連のユーザーインターフェイスコントロールを操作するときは、インテリセンスが機能するようにしたいと考えています。それを達成するために、私は通常、「uxSomeControlName」のプレフィックスを持つコントロールの ID を作成します。このようにして、そのテキストボックスを探してテキスト値を取得するときに、「ux」と入力するだけで、すべてのユーザーインターフェイス ID が表示されます。txt、ddl、grd などを検索する必要はありません。

上記を読んだ場合、これは正しいです。いいえ。しかし、ただ 2 文字しか知らなくてもいいのに、何十個もコントロール名を覚えようと座って聞いたりしたくはありません。

私が言ったように、これはフロントエンドで作業しているときだけです。

score 0 · Accepted Answer

C＃で検討する唯一のプレフィックスは、次のようなメンバー変数の_です。

public class Test
{
    private int _id;
}

score 0 · Accepted Answer

私はときどき、pName が関数に渡されるパラメーターである一種のプレフィックスを使用します (型のプレフィックスを付けていないことに注意してください)。oName は現在のメソッドに対してローカルであり、mName は現在のクラスのメンバーであり、cName は定数または静的読み取り専用メンバー。

個人的には助かります。

score 0 · Accepted Answer

0

存在しない問題の解決策。

于 2008-11-21T17:50:39.957 に答える

score 0 · Accepted Answer

短い答えはノーです。しかし...

ハンガリー語の表記法から離れることの重要性は理解しています。私たちの店の標準でも禁止されていますが、1 つの理由と 1 つの理由だけで、1 回限りのまたは小さなユーティリティプロジェクトでハンガリー語表記法が依然として有用であることがわかります。 Web または Win フォームの多数のコントロールでは、HN を使用すると Intellisense が使いやすくなり、コーディング中にすべてのコントロールを確実にキャッチできます。

5 つのチェックボックスがあり、それらの名前がすべて chk で始まる場合、chk と入力すると、すべてのリストが表示され、その時点で作業しているチェックボックスを簡単に選択できます。

また、「あのチェックボックスの名前は何だったの？」と思うこともあります。そして、中断して .ASPX ページをもう一度見なければなりません。

私が妥協した 1 つの方法は、HN から始めることです。次に、win または Web フォームのメインコードを完成させたら、最後のステップは、HN という名前のコントロールのグローバルな名前変更を行うことです。これは実際に私にとってはうまくいきました。もちろんYMMVです。

score 0 · Accepted Answer

型のセットが限られている最近のほとんどの言語では、特に署名されていない型の概念がないため、名前の付いた変数に接頭辞は必要ありません。

signed 型と unsigned 型、または多数の同様の型 (short、int、long、Int8、Int16、In32 など) を持つ言語では、他の誰かが何を言おうとしていようと (そして彼らが言おうとしていることとは関係なく)、接頭辞は役に立ちます。それ）。

コンパイラーはせいぜい、式に異なる符号の整数型を混在させようとしたときに警告を出すだけであり、たとえばビルドインで (警告ではなく) エラーのみを表示するように IDE を構成すると、これは簡単に見落とされる可能性があります。最終的な要約 (Visual Studio でできるように)。算数で記号を混ぜると、1 日が台無しになる可能性があるため、あなたや後継者の頭痛の種を救い、手がかりを与えてください。覚えておいてください - コードを見るのはあなただけではありません。

score 0 · Accepted Answer

今日、多くのプログラマーがそれを放棄していますが、私は特定のケースではまだ使用しています。それらのいくつかを次に示します。

すでにそれを使用しているコードを維持している場合は、引き続き使用します。
あなたの会社のスタイルのガイドラインがまだそれを必要としている、または提案している場合。
ドキュメントに変数の単純な英数字順のリストがある場合、タイプのようなグループ化に役立ちます。

score -1 · Accepted Answer

いいえ、メソッドが長すぎて使用と同時に定義を読み取ることができない場合、または名前がタイプを意味しない場合は、名前を付けるだけでなく、より深刻な設計上の問題が発生します。

ただし、txtNameなどのタイプでプレフィックスコントロールを実行することを強くお勧めします。

c# - 可変接頭辞（「ハンガリアン記法」）はもう本当に必要ですか？

29 に答える 29

いいえ！

Related

Reference