システムハンガリー語表記はまだ有用な方法ですか？
フォーラムを検索しましたが、なぜそれを避けなければならないのか、なぜそれが特効薬ではないのかという答えは見つかりませんでした。だから私はこの質問が重複しているとは思いません。
[〜＃〜] valid [〜＃〜]慣れているシステムハンガリー語の学習をやめるべき理由はありますか？
これまでのところ、それを使用することには次のような利点があります。
- 一貫した変数の命名
- 検索せずにタイプが表示されます（インテリセンスは半分の時間でデッド/インデックスを作成するため、それでも正当な理由です）
- セマンティクスは引き続き名前の2番目の部分にパックできます
そして次の欠点：
- 一部の人を困らせる（理由がわからない）
- タイプが変更された場合、タイプは変数の名前と一致しない可能性があります（正当な理由ではないと思います。タイプが変更されることはほとんどなく、「すべて名前を変更」する必要があります）
なぜ：
vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.Push_back(strCity);
より悪い：
vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.Push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?
私は（何年も前に）それを使用していましたが、もう使用していません。主な理由は、OO強力な型指定（C++、Java）を備えた言語で、たまたま私のキャリアの大部分を使用していたことです。これらの言語では、型を適切に定義すると、コンパイラーは私にタイプセーフを強制することができますし、そうするつもりです。
よく書かれたOOプログラムでは、ほとんどの変数はユーザー定義型（への参照）です。これらに同じ一般タグを付けます（ "object"のoなど） ）、メリットはありませんが、デメリットのみが得られます。ただし、タイプ固有のタグをプレフィックスとして付けると、よく似た名前を持つ1000の異なるタイプの異なる略語を見つけようとする迷路に入ります*。タイプまたはその名前が変更されたときは、それらすべてを変更することを忘れないでください（よく管理されたプログラムでは、これはまったく珍しいことではありません）。
もちろん、これはOO以外の言語には適用されず、弱く型付けされた言語や動的に型付けされた言語には適用されない可能性があります（C以外に、これらの言語の経験はありません）。使用可能なIntelliSense（またはそのローカルの同等物）がない次善のエディター/ IDEにも。そして、これはちょうど私の2セントです。ハンガリー記法があなたのチームとあなたのプロジェクトのために働くなら、それのために行きなさい。重要なことは、これに（そして一般に一貫したコーディングスタイルに）同意することですbeforeプロジェクトが開始し、常に一貫性を保ちます。
*現在のプロジェクトからの短いリスト：Charge、ChargeBreakdown、ChargeCalculator、ChargeDAO、ChargeDTO、ChargeLineHelper、ChargeMaps、ChargePair、ChargeTypeなど。さらに、Contracts、Countries、Checkouts、Checkins ...もあります。これは、おそらくCではありませんが、 OPによって「適切なサイズ」と呼ばれることさえあります。
免責事項：私は実際にはハンガリー人なので、この問題について当局と話すことができると思います;-)
なぜstd::vector<string> vecCityNames;悪い？
ハンガリー語表記の問題は通常使用されるため、プロファイリングで都市名をstd::deque、そのタイプのオブジェクトを参照するすべての変数名は、突然誤解を招く名前になります。
次に、すべての変数の名前を変更しますか？大きなプロジェクトでこれをやろうとしたことがありますか？マーフィーの助けがあれば（そしてその人は信じられないほど役に立ちます）誰かがdeqCityNamesなどの変数と呼ばれる変数を使用し、変更がビルドを壊し、コードをいじくるのに何十年も座ったままになるでしょう。 、有毒な獣に噛まれるのを恐れて、誰もそれを見ようともしなかった。
しかし、私が知っていることから、Charles Simonyiがハンガリー語を思いついた方法では、接頭辞は変数semantic usageを示していました、 構文タイプではありません。つまり、都市名のリストの適切なプレフィックスは、それが実装されているタイプに関係なく、おそらくlistCityNames（またはlstCityNamesでない場合はlistになります）あなたのために十分に不可解です）。
しかし、複数形（「名前」）はすでにそれが都市の集まりであることを伝えているので、私はその接頭辞をかなり不必要だと考えています。結論：識別子を慎重に選択する場合、ハンガリー語表記はほとんど必要ありません。 OTOH、それが一般的に使用されている方法は、長期的には、実際にコードに損傷を与えています。
何らかの理由で、ここでの既存の答えは、ハンガリー語表記の根拠を明記せずに、その根拠に沿って踊っているようです。ハンガリー語表記は、言語自体では型情報を追加するのが困難な場合に、型情報（ 型理論的意味 ）を追加するのに便利です。たまたま、C++やJavaの型システムをハンガリー語の表記（通常は説明されている）が完全に不要になるように使用することは通常それほど難しくありません。これがおそらく反発の原因です-プログラマーの作業を追加するこれらの注釈をすべての変数領域で維持しますが、追加の値をほとんどまたはまったく提供しません（コードが雑然として見えるため、害を及ぼす可能性さえあります）。
一方、ハンガリー語表記の使用をタイプ情報に制限する場合（これも タイプ理論的意味で ）、つまりnot言語によって自然にカプセル化されるため、非常に便利です。たとえば、CおよびC++は配列参照をポインター型として渡しますが、配列参照とポインターはそれらに対して実行する必要のある異なる操作を持っています。配列は最初の要素を超えてインデックス付けできますが、ポインターはそうではありません。これは、配列が引数として関数に渡されるとすぐに型システムに失われる有用な情報です。そのため、私たちのグループでは、ポインター変数が実際に単一の要素へのポインターであるか、配列へのポインターであるかを区別するために、CおよびC++コードで変数名アノテーションを採用しています。この規則を採用することは、コードベースでのメモリ破損の問題の発生を大幅に削減することに部分的に関与しています。
嫌いは言葉、IMOが強すぎます。コードは好きなように書くことができます。私は自分のコードでハンガリー語の表記法を使用しないことを好み、他の人のコードでそれを読んだり操作したりする必要がないことも選択したいと思います。
一部の人々がハンガリー語の記法を不快に思う理由を尋ねました。私は他の人のために話すことはできませんが、それが私を困らせる理由は：
醜いです。ハンガリー語は完全に合理的な名前を取り、コードに相当するものを先頭に追加します。このコードを内部化したら、きっと完全に理にかなっていますが、初心者にとっては、誰かが私のソースコードでC++の名前を解き放ったように見えます。
冗長です。変数の宣言は、その型を確立します。変数名でその情報を繰り返す必要はないと思います。これはすべての言語に当てはまるわけではありません。たとえば、Perlでは、変数名の前に@または$などのシギル本質的に変数の型を定義するので、それらを使用する以外に選択肢はありません。
それは私が持っていない問題を解決します。メソッドと関数は、ローカル変数またはパラメーターの宣言を見つけるのに一生懸命に探す必要があるほど長くなければなりません。変数が多すぎるため、何が何であるかを追跡するのが困難です。ローカル変数を使用するコードの近くでローカル変数を宣言すると、この点でも役立ちます。過去のCコンパイラでは、すべてのローカル変数を関数の先頭で宣言する必要がありましたが、その制限はずっと前に削除されました。
それは不完全です。ハンガリー語の表記法は、型システムを持たない言語（BCPL）のために考案され、その後、かなり限られた数のネイティブ型を持つ言語（C）で広く使用されました。 IMO、それはC++やJavaなどの広範な型システムを持つ言語ではうまく機能しません。なぜプレフィックスを使用して、次のようなネイティブ型の変数の型を示す必要があるのですか？ char []ですが、クラスではありませんか？代わりに、クラスの
vecのような接頭辞を発明し始めると、クラス階層に平行な接頭辞の大きな階層ができてしまいます。 、どういたしまして。それについて考えるだけで頭痛の種です。あいまいです、少なくとも私が理解している限り。
szFooとpszFooの違いは何ですか？最初はゼロで終了する文字列で、2番目はゼロで終了する文字列へのポインタです。しかし、CまたはC++では、私が知る限り、文字列変数は事実上ポインタであるので、同じかどうかはわかりません。どちらを使用すればよいですか？実際の答えは実際には問題ではありません-ポイントは、この種の質問を回避するのに役立つはずの表記法では答えを識別できないということです。一方、変数の宣言は、コンパイラが使用するものであるため、明確でなければなりません。
それらはハンガリー語の記法についてmeを困らせるものです。グループとしてでも、ハンガリー人がほとんど見捨てられた理由を彼らが完全に説明しているとは思いません。ほとんどのプログラマーがハンガリー語を使用しない3つの最大の理由は次のとおりです。
使用する説得力のある理由はありません。上記の項目3と4を参照してください。もしハンガリー語がハンガリー語を使わないことよりも大きな利点を提供してくれれば、私はおそらく煩わしさを抱えて生きることができるでしょうが、私はそれを知りませんし、他のほとんどの人々もそうではありません。おそらくハンガリー語の最も優れた点は、それが広く使用されている規則であることであり、標準的な使用法に固執した場合、同様のスキルを持つ他のプログラマーが表記法を理解できると合理的に期待できます。
Microsoft以外の企業の影響力の増大。ハンガリー語の表記法を採用したほとんどのプログラマーがそうしたのは、Microsoftがコードを記述した方法であり、多くの場合フローに合わせやすいためです。 GoogleやAppleのような企業は、今までよりもはるかに大きな影響力を持っています。そして、これまで以上に多くのプログラマーが、ハンガリー語を避けている企業や他の企業のスタイルを採用しています。 （GoogleとAppleはしばしば定数名に 'k'接頭辞を使用します。）のように、いくつかの残骸がまだ表示されていることを指摘するのは公平です。
Microsoft自身がハンガリー語を放棄しました。 Microsoftのコーディングガイドラインの 一般的な命名規則 セクションを確認すると、太字で書かれていることがわかります：しないでくださいハンガリー語表記を使用してください。
したがって、ハンガリー語表記の使用をやめる正当な理由の1つは次のとおりです。
ハンガリーの表記法の人気は、この条約が役に立たなくなるほどに減少しました。最近、ハンガリー語を使用したり理解したりするプログラマーははるかに少ないため、この条約は、想定されている情報を伝えるのにあまり効果的ではありません。 。自分の個人的なプロジェクトでコードを書くのに便利な方法だと思ったら、やめるべき理由はほとんどありません。ただし、ハンガリー語を使用しないチームの一部としてコードを記述している場合、コミュニケーション戦略が成功するのではなく、チームと他のメンバーとの間の壁になる可能性があります。
一部の人を困らせる（理由がわからない）
それが私を困らせる理由は、コードの視覚的なスキャンを遅くするのは、すべての単一の識別子に対する小さな速度のバンプだからです。これはmAsですbIf pYou kHad zTo qRead iEnglish cText llike uThis。
これまでのところ、それを使用することには次のような利点があります。
- 一貫した変数の命名
シンプソンズのキャラクターにちなんですべての変数に名前を付けても、一貫性がありますが、それはメリットですか？
- 検索せずにタイプが表示されます（インテリセンスは半分の時間でデッド/インデックスを作成するため、それでも正当な理由です）
これは、特定のツールの弱点に基づく唯一の正当な理由です...
- セマンティクスは引き続き名前の2番目の部分にパックできます
それは利点ではありません。 （massive）のマイナス面がないと主張しているだけです。
IDEは、マウスを上に置くと、変数のタイプが何であるかを自明に教えてくれます。それで、なぜその情報を複製する必要があるのでしょうか？その情報が現代の環境で簡単にアクセスできる場合、その代金を支払う理由はありません。
一貫性は、それ自体の利点ではありません。タイプでそれらに名前を付けないことはalsoでも一貫しています。名前にいくつかの変数の型が含まれている場合にのみ、矛盾が発生します。そして、セマンティクスを2番目の部分にパックすることは、単に「まあ、それほど悪くはない」です。他の誰もがセマンティクスにwholeの名前を使用できます。リストされている実際の利点はありません。
ハンガリー語表記の従来の形式のもう1つのポイントは、通常は接頭辞であるということです。ここには2つの問題があります。
1）人間の読者は一般的に最も重要な情報を最初に好むでしょう。ハンガリー語のほとんどの形式では、エンコードされた情報はおそらく名前自体よりも重要性が低いです。
2）プレフィックスは字句ソートに影響を与えるため、たとえば、インターフェースまたはクラスを示すためにプレフィックスを使用し、IDEがこれらのソートされたリストを提供する場合、関連するクラス/インターフェースはこのリストで区切られています。
明らかに、これは意見に帰着するので、ここで事実を扱うことは難しいでしょう。個人的には、引数forハンガリー語の表記は、強く型付けされたオブジェクト指向言語では少し細いことに気づきます。私の経験では、OOアプリケーションは、クラスを一貫性のある簡潔な状態に保つことによって複雑さを処理する傾向があり、関数についても同じことが言えます。
- その他のクラス/タイプ
- より短い方法
ここで、ハンガリー語表記を使用する場合は、それを全面的に適用するか、特定の特権タイプおよびクラス（コアライブラリクラスなど）にのみ使用するかを決定する必要があります。後者は私には意味がありません、そして前者はペター・トレックが言及していた「千の異なるタイプへの異なる略語を見つけようとする迷路」につながります。これは、略語リストを維持するのにかなりのオーバーヘッドがあり、通常「一貫した変数の命名」がウィンドウの外に出ることを意味します。
短いメソッドに関する2番目のポイントは、ほとんどの場合、変数のタイプを確認するために何百行ものコードを調べる必要がないことを意味します。変数にもう少し慎重に名前を付けると、他のいくつかの質問がなくなります。 cityName対city。 cityNameがfloatでないことを願っています:)
それが人々を苛立たせる理由に関して-再び、これはおそらくそれに慣れているかどうかにかかっています。しかし、慣れていない人としては、ハンガリー語の表記法を使用すると、コードの流れが分からなくなり、すぐに読むことが難しくなることがわかります。要約すると、それはnoメリットがあるとは言っていません（ただし、リファクタリングなどの点で、その欠点のいくつかについては説明していません）。この取り組みには価値がないと言っています。強く型付けされた、OO言語。
C++のコンテキストではわかりませんが、Java/C＃の世界では、ドメイン言語またはコンテキストのいずれかを伝える意味のある名前を使用するほうが、strFirstNameが文字列;それが文字列であること、またはより良い意図を伝えるために名前をリファクタリングする必要があることは明らかです。使用しているもののタイプを知るためにプレフィックスをrequireしている場合、名前が一貫していないか、説明が不十分であるか、まったく間違っていると私は主張します。現代の言語では、曖昧な名前やあいまいな名前よりもあいまいさを残さない長い名前を常に好みます。
私がハンガリー語を使用する唯一の時間はASP.NETコントロール用であり、それはIA）CustomerFirstNameTextBoxとtxtCustomerFirstNameのような本当に長いものを入力する必要がないため、B）Intellisenseがソートしますすべてのコントロールタイプ。それでも「汚い」と感じますが、まだもっと良い方法を見つけることができていません。
答えはこの質問にあります：次の変数に名前を付ける方法を教えてください：
char * nullTerminatedString; wchar * nullTerminatedWideString; string stlString; wstring stlWideString; CString mfcString; BSTR comString; _ bstr_t atlString;
これらの定数文字列に、これらへのポインタとこれらへの定数ポインタを追加します。
私はあなたが説明するハンガリーの記法の形を強く嫌います。理由？それは90％の時点で役に立たない。
たとえば、私が我慢しなければならないレガシープロジェクトからの（同等のC++。実際にはDelphiで書かれた）コードのビット：
pRecords[0]->FooMember=10;
... pRecordは変数で、TRecordList型です。 TRecordList *pRecords[10];
これは、「フィールド」または「メンバー」のどちらであるかに応じて、fFooMember ...またはmFooMemberを指すFooMemberという名前のorioertyで構成されるクラスです（ヒント：同じものです）
問題？ fFooMemberは、FooMemberパブリックプロパティを通じて常にアクセスするため、FooMember_のようになります。 pRecords？あちこちで逆参照しているという事実からのポインタであることは明らかです。 TRecordList？型名とその型のオブジェクトを混同する可能性があるのはいつですか？コンパイラはあなたに怒鳴り、型はオブジェクトが存在する場所でほとんど使用されません（静的プロパティ/メソッドを除く）
今、私がハンガリーの記法を使う場所が一つあります。これは、他のUI変数または通常の変数と同じ名前を持つ多くのUI変数を扱う場合です。
たとえば、私があなたの名のフォームを持っていたとします。
FirstNameFormという名前のクラスがあります。その中で、lblFirstNameとtxtFirstNameはそれぞれラベルとテキストボックスです。また、テキストボックスで名前を取得および設定するためのパブリックFirstNameプロパティ。
これはFirstNameLabelとFirstNameTextBoxを使用して解決することもできますが、入力に時間がかかります。特にGenderDropDownListのようなもので。
したがって、基本的に、ハンガリー語の表記は、せいぜい体系的なレベルで迷惑であり、最悪の場合は有害です（他の回答ではリファクタリングと一貫性の問題について説明しています）。
Meh-それは個人がどのように選択を合理化しようと努力しても、個人の好みに関するものです。私は個人的には「ローマにいるとき...」というルールを守り、Windows APIを頻繁に呼び出すコードでハンガリー語を使用しています。プラットフォームに依存しないコードの場合、私はC++標準ライブラリスタイルに従う傾向があります。