「ハンガリー語表記」を使用してはいけないのはなぜですか?

https://stackoverflow.com/questions/111933

02-07-2019
|

質問

ハンガリー語が何を指すのか、変数、パラメーター、または型に関する情報をその名前の接頭語として与えることを私は知っています。たとえ場合によってはそれが良いアイデアであるように見えても、誰もがそれに猛烈に反対しているようです。有益な情報が伝えられていると感じるなら、それを入手可能な場所に掲載すべきではないでしょうか?

以下も参照してください。現実世界でもハンガリー語の命名規則を使用している人はいますか?

解決

ほとんどの人はハンガリー語表記を間違った方法で使用しており、間違った結果が得られています。

Joel Spolsky によるこの素晴らしい記事をお読みください。間違ったコードを間違ったものに見せる.

つまり、ハンガリー語表記では、変数名にその変数名を接頭辞として付けます。 type (文字列) (システムハンガリー語) は役に立たないので悪いです。

作成者が意図したハンガリー語表記で、変数名の前に次の文字を付けます。 kind (ジョエルの例を使用:安全な文字列または安全でない文字列）、いわゆる Apps Hungarian には用途があり、依然として価値があります。

他のヒント

vハンガリー語の注釈を使用すると、ncode の読み取りが困難になります。

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

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

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

しかし、ほとんどの言語に欠けているのは、この種の区別を強制するのに十分な表現力を持つ型システムです。たとえば、C に一種の「強力な typedef」(typedef 名に基本型のすべての操作が含まれるが、基本型に変換できない) があれば、これらの問題の多くは解決します。たとえば、次のように言うことができます。 strong typedef std::string unsafe_string; 新しいタイプを導入する unsafe_string これは std::string に変換できませんでした (そのため、オーバーロードの解決などに参加する可能性があります)。など）その場合、愚かな接頭辞は必要ありません。

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

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

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

また、強く型付けされた言語ではあまりメリットがありません。何らかの形式の不一致 tomfoolery を実行すると、コンパイラはそれについて通知します。

ハンガリー語表記は言語内でのみ意味を持ちます ユーザー定義型なし. 。最新の関数型言語または OO 言語では、値の「種類」に関する情報を変数名ではなくデータ型またはクラスにエンコードします。

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

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

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

ハンガリー語のアプリ 従来の VBScript や初期バージョンの VB など、ユーザー定義型のない言語を使用している場合は意味があります。Perl や PHP の初期バージョンも含まれる可能性があります。繰り返しますが、これを現代言語で使用するのは純粋な貨物崇拝です。

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

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

私はすべてのプロジェクトで常にハンガリー語表記を使用しています。何百もの異なる識別名を扱う場合、これは非常に役立つことがわかります。

たとえば、文字列を必要とする関数を呼び出す場合、「s」と入力してコントロールスペースを押すと、IDE は接頭辞「s」が付いた変数名を正確に表示します。

もう 1 つの利点は、符号なし int に u 、符号付き int に i というプレフィックスを付けると、潜在的に危険な方法で符号付きと符号なしが混在している箇所がすぐにわかることです。

75,000 行にも及ぶ巨大なコードベースで、ローカル変数にそのクラスの既存のメンバー変数と同じ名前を付けたためにバグが (私や他の人によっても) 引き起こされたことが何度あったか思い出せません。それ以来、メンバーの前に常に「m_」を付けるようにしています

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

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

はい、IDE がタイプをすぐに識別します。ただし、「ビジネスルール」コードの長いバッチを読んでいるときは、変数の型を確認するために各変数で一時停止する必要がないのは便利です。strUserID、intProduct、guiProductID などを見ると、 多くの 「立ち上げ」時間が容易になります。

MS がいくつかの命名規則を行き過ぎていることに私は同意します。私はそれを「良すぎること」の山に分類します。

命名規則は、それを守っていれば良いものです。古いコードを何度も調べたので、同じような名前の変数の定義を何度も確認する必要があり、「キャメルケーシング」 (以前の仕事で呼ばれていた) をプッシュしました。現在、私は VBScript を使用した完全にコメントのない古典的な ASP コードを何千行も扱う仕事をしていますが、それを理解するのは悪夢のような作業です。

各変数名の先頭に不可解な文字を追加するのは不要であり、変数名だけでは十分に説明的ではないことがわかります。ほとんどの言語ではとにかく宣言時に変数の型を必要とするため、その情報はすでに入手可能です。

また、メンテナンス中に変数の型を変更する必要がある場合もあります。例：「uint_16 u16foo」として宣言された変数を 64 ビット符号なしにする必要がある場合、次の 2 つのうちのいずれかが起こります。

各変数名を確認して変更します (無関係な変数を同じ名前でホースしないように注意します)。または
名前は変更せずにタイプを変更するだけです。混乱を招くだけです。

Joel Spolsky がこれについて良いブログ投稿を書きました。http://www.joelonsoftware.com/articles/Wrong.html基本的に、きちんとした IDE が変数の型を思い出せない場合に指示する場合に、コードを読みにくくしないことが重要になります。また、コードを十分に区分化すれば、3 ページ上で宣言された変数を覚えておく必要はありません。

最近はタイプよりもスコープの方が重要ではないでしょうか。

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

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

作らない理由はない 正しい ハンガリー語表記の使用。不人気の原因は長期にわたる反動によるものである。悪用特に 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 には近距離と遠距離の 2 種類のポインタがありました。したがって、たとえば、メモリ管理関数 LocalLock からの戻り値は PVOID でしたが、GlobalLock からの戻り値は LPVOID (長い「L」が付きます) でした。その後、そのひどい表記法が拡張されて、私オング pointer文字列が接頭辞として付けられました LP, 、単純に malloc された文字列と区別するためです。

この種のことに反発があったのは不思議ではありません。

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

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

一方で、コンパイル時の型チェック言語でもハンガリー語表記の恩恵を受けるケースもあり得ます。空所ポインタまたは ハンドルは win32 API にあります。これらは実際のデータ型を難読化するため、そこにハンガリアン表記を使用するメリットがあるかもしれません。しかし、構築時にデータの型を知ることができるのであれば、適切なデータ型を使用しない理由はありません。

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

Python プログラマーにとって、ハンガリー語表記はすぐに壊れてしまいます。Python では、何かあっても気にしないは文字列 - できるかどうかは気にします のように振る舞う 文字列 (つまり、ある場合 ___str___() 文字列を返すメソッド)。

たとえば、foo が整数 12 であるとします。

foo = 12

ハンガリー語の表記法では、それが整数であることを示すために、それを iFoo か何かと呼ぶべきだと教えてくれます。そうすれば、後でそれが何であるかを知ることができます。Python 以外ではこれは機能しません。というより、意味がありません。Python では、使用するときにどの型が必要かを決定します。文字列が欲しいですか？さて、私が次のようなことをすると:

print "The current value of foo is %s" % foo

注意してください %s - 弦。Foo は文字列ではありませんが、 % オペレーターが電話します foo.___str___() そしてその結果を使用します (それが存在すると仮定します)。 foo は整数のままですが、文字列が必要な場合は文字列として扱います。float が必要な場合は、それを float として扱います。Python のような動的型付け言語では、ハンガリー語表記は無意味です。使用するまでは、何かがどのような型であるかは問題ではありません。また、特定の型が必要な場合は、必ずその型にキャストするだけです (例: float(foo)）使用するとき。

PHP のような動的言語にはこの利点がないことに注意してください。PHP は、ほとんど誰も覚えていないあいまいなルールのセットに基づいてバックグラウンドで「正しいこと」を行おうとするため、予期せぬ壊滅的な混乱を招くことがよくあります。この場合、次のような何らかの名前付けメカニズムが使用されます。 $files_count または $file_name, 、便利かもしれません。

私の考えでは、ハンガリアン記法はヒルのようなものです。おそらく以前は便利だった、あるいは少なくとも便利だと思われていましたが、今では余計な入力が必要になるだけで、あまりメリットはありません。

IDE はその有用な情報を提供する必要があります。ハンガリー語は、IDE がそれほど進歩していなかったときに、ある種の (大したことではありませんが、ある種の) 意味を理解していたかもしれません。

私にとってハンガリー語は良い意味でギリシャ語です

プログラマーではなくエンジニアとして、私は Apps Hungarian の利点についての Joel の記事をすぐに読みました。「間違ったコードを間違ったものに見せる」. 。私はハンガリー語のアプリが好きです。 工学、科学、数学が下付きおよび上付きの記号を使用して方程式や公式を表現する方法を模倣します。 (ギリシャ文字、数学演算子など)。特定の例を挙げてみましょうニュートンの万有引力の法則:最初は標準の数学表記で、次に Apps ハンガリー語の疑似コードで記述します。

Newton's Universal law of gravity for Earth and Mars

frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)

数学的表記において、最も顕著な記号は、親切変数に格納される情報:力、質量、位置ベクトルなど添字は、明確にするために 2 番目のフィドルを再生します。何の位置？これはまさに Apps Hungarian が行っていることです。それはあなたに伝えています親切最初に変数に格納されているものの内容を確認してから、詳細に進みます。数学的表記法に最も近いコードについて説明します。

明らかに強力な型付けにより、安全性と安全性の問題を解決できます。Joel のエッセイからの安全でない文字列の例ですが、位置ベクトルと速度ベクトルに別々の型を定義することはありません。どちらもサイズ 3 の double 配列であり、一方に対して行うことは他方にも適用される可能性があります。さらに、位置と速度を連結する (状態ベクトルを作成する) か、それらの内積を取得することは完全に理にかなっていますが、おそらくそれらを加算することはできません。入力では、最初の 2 つはどのように許可され、2 番目は禁止されるのでしょうか。また、そのようなシステムは、保護したい可能性のあるすべての操作にどのように拡張されるのでしょうか?数学と物理学のすべてをタイピングシステムでエンコードしたい場合は別です。

それに加えて、エンジニアリングの多くは、Matlab のような弱く型付けされた高級言語、または Fortran 77 や Ada のような古い言語で行われています。

したがって、高級な言語を使用していて、IDE やアプリのハンガリー語が役に立たない場合は、それを忘れてください。どうやら多くの人がそうしているようです。しかし、脆弱な言語や動的型付け言語を使用する初心者プログラマーよりも劣る私の場合、Apps Hungarian を使用した方が、使用しないよりも速く、より良いコードを書くことができます。

最近の IDE では型を明確にするのがうまく機能しますが、これは信じられないほど冗長で役に立ちません。

さらに、私にとっては、intI や strUserName などを見るのは単に煩わしいだけです。:)

有益な情報が伝えられていると感じるなら、それを入手可能な場所に掲載すべきではないでしょうか?

それでは、他の人が何を考えているかなど誰が気にするのでしょうか？役立つと思われる場合は、その表記を使用してください。

私の経験では、それは次の理由で悪いことです。

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

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

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

で Joel Spolsky が間違ったコードを間違ったものに見せる彼は、誰もがハンガリー語記法と考えているもの (彼はシステムハンガリー語と呼んでいます) は、実際に意図されていたもの (彼がアプリハンガリー語と呼んでいるもの) ではないと説明します。下にスクロールして、 私はハンガリーです このディスカッションを見るために向かっています。

基本的に、システムハンガリー語には価値がありません。コンパイラや IDE が伝えるのと同じことを伝えるだけです。

Apps Hungarian は変数が何を意味するのかを示し、実際に役立ちます。

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

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

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

次のコードスニペットを見てみましょう。

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

誰かがハンガリー語を使わずにコントロール名を設定するより良い方法を示してくれたら、私はそれに移りたくなるでしょう。

Joel の記事は素晴らしいですが、重要な点が 1 つ抜け落ちているようです。

ハンガリー人は、コードベース全体で、特定の「アイデア」（Kind + Identifier Name）をユニークな、またはほぼユニークにします。

これはコードのメンテナンスにとって非常に大きなことです。つまり、昔ながらのシングルラインテキスト検索（GREP、FindStr、「Find in Find」）を使用して、その「アイデア」のすべての言及を見つけることができます。

コードの読み方を知っている IDE があるのに、それがなぜ重要なのでしょうか?彼らはまだあまり上手ではないからです。これは小さなコードベースでは見るのが難しいが、大規模なコードベースでは明らかです - コメント、XMLファイル、PERLスクリプト、およびソースコントロール外の場所（ドキュメント、WIKI、バグデータベース）で「アイデア」が言及される可能性がある場合。

ここでも少し注意する必要があります。C/C ++マクロでのトークンパスティングは、識別子の言及を隠すことができます。このようなケースは、コーディング規則の使用に対処することができ、とにかくコードベース内の識別子の少数にのみ影響する傾向があります。

追伸型システムの使用とハンガリー語 - 両方を使用するのが最善です。コンパイラーがそれをキャッチしない場合にのみ、間違ったコードが間違っているように見えます。コンパイラにそれをキャッチさせることが不可能な場合もたくさんあります。ただし、それが可能な場合は、代わりにそうしてください。

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

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

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

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

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

ハンガリー語の表記法では変数名を使うのが面倒になることがわかりました。彼らはそれを区別する何かを持っており、その目的を詳しく説明する必要はないと感じています。これは、ハンガリー語表記のコードとハンガリー語表記のコードでよく見られるものです。モダンな：sSQL とgroupSelectSql (または、以前の開発者によって組み込まれた ORM を使用することになっているため、通常は sSQL がまったくありません。)、sValue とフォームコレクション値 (または、通常は sValue もありません。それらはたまたま MVC にあり、そのモデルバインディング機能を使用する必要があるためです。)、sType とソースなどを公開します。

それは可読性ではあり得ません。さらに sTemp1、sTemp2 が表示されます...ハンガリー語の VB6 の残りからの sTempN は、他のすべてを合わせたものよりも多くなります。

エラーを防ぎます。

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

マスターの言葉では次のようになります。

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

いつものように興味深い読み物です。

抜粋:

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

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

Joel On Software を読む前に、少し時間があることを確認してください。:)

いくつかの理由：

最新の IDE では、変数の上にマウスを置くだけで変数の型が表示されます。
ほとんどの型名は非常に長いです ( HttpClientRequestProvider) プレフィックスとして合理的に使用されます。
型情報には、右情報としては、変数宣言の概要を説明するのではなく、単に変数宣言を言い換えているだけです。目的変数の（考える） myInteger 対 ページサイズ).

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

Joel は、ハンガリー語を使用して変数が HTML エンコードされているかどうかを判断することに関する素晴らしい記事を書いています。

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

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

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

詳細な議論については、このテーマに関して私が作成したブログ投稿を参照してください。

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

私がコーディングを始めたのは、ハンガリー語表記法が発明された頃で、初めてプロジェクトでハンガリー語表記法の使用を強制されたときは、それが嫌でした。

しばらくして、それが適切に行われると実際に役立つことに気づき、最近ではそれが気に入っています。

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

ハンガリー語の表記法は、特に Microsoft によって乱用され、変数名よりも長いプレフィックスが付けられ、特に型を変更する場合 (悪名高い lparam/wparam、Win16 では型/サイズが異なり、Win32 では同一) が非常に厳格であることが示されました。）。

したがって、この乱用と M$ による使用の両方により、それは役に立たないものとして削除されました。

私の職場では Java でコードを作成していますが、創設者は MFC の出身なので、同様のコードスタイルを使用します (整列中括弧、これが気に入っています!、メソッド名には大文字、私はそれに慣れています、クラスメンバー (フィールド) には m_ のような接頭辞を付けます) )、静的メンバーへの s_ など)。

そして、すべての変数にはその型を示すプレフィックスが必要であると彼らは言いました（例：BufferedReader の名前は brData)。これは悪い考えであることが示されています。型は変更できても名前が従わない、またはコーダーがこれらのプレフィックスの使用に一貫性がないためです (aBuffer、theProxy なども見られます!)。

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

したがって、基本的に、私はこの表記法全体を否定しませんが、私のニーズに適していると思われるものを採用しました。
そしてもちろん、何らかのプロジェクト (仕事、オープンソース) に貢献するときは、定められた規則をそのまま使用します。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow