ハンガリー記法を使用しないことの利点は何ですか？

私が苦労していることの1つは、ハンガリー記法を使用していないことです。私はしていないだけで、それが何であるかのタイプを参照する変数の定義に行かなければならたいです。プロジェクトが大規模になると、「bool」という接頭辞が付いた変数を見て、0/1値ではなくtrue / falseを探していることを知ることができてうれしいです。

SQL Serverでも多くの仕事をしています。データベース内のすべての変数は言うまでもなく、ストアドプロシージャの先頭に「sp」、テーブルに「tbl」を付けます。

ハンガリーの表記法を実際に使用したくない人は誰もいないと思うので、それを避けます。私の質問は、ハンガリーの表記法を使用しないことの利点は何ですか？また、大多数の開発者がペストのようにそれを避けるのはなぜですか？

当初の意図（http://www.joelonsoftware.com/articles/Wrong.htmlおよびhttp://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroidsを参照）が誤解されており（ ab）使用する言語が静的に型付けされていないときに、変数の型を思い出すために使用されます。静的に型付けされた言語では、変数の型を示すためにプレフィックスのバラストを追加する必要はありません。多くの型付けされていないスクリプト言語では役立ちますが、完全に扱いにくくなるまで悪用されていることがよくあります。残念ながら、ハンガリーの表記の元の意図に戻る代わりに、人々はあなたが避けるべき「悪」なものの一つにしたのです。

要するにハンガリー語の表記法は、変数の前にいくつかのセマンティクスを付けることを目的としていました。たとえば、画面の座標（左、上、右、下）がある場合、変数の前に絶対画面位置のabs変数を" "で、ウィンドウに相対的な位置の変数に" "を付けますrel。そうすれば、絶対位置を必要とするメソッドに相対座標を渡すと、読者には明らかです。

更新（delnanによるコメントへの応答）

私見、虐待されたバージョンはペストのように避けるべきです：

• 命名が複雑になります。ハンガリー記法を使用する場合（ab）、接頭辞がどの程度具体的である必要があるかについて、常に議論が行われます。例：listboxXYZまたはMyParticularFlavourListBoxXYZ。
• 変数の目的を理解するのを助けずに、変数名を長くします。
• 長いプレフィックスを避けるためにこれらが略語に短縮され、各略語が何を意味するかを知るための辞書が必要な場合、それはある種の演習の目的を無効にします。あるui符号なし整数？参照されていないカウントされたインターフェース？ユーザーインターフェースと関係がある？そして、それらは長くなる可能性があります。私は、varの正確なタイプを伝えるはずの15以上のランダムに見える文字の接頭辞を見てきましたが、実際には単に神秘的なものです。
• すぐに古くなってしまいます。変数の型を常に変更する場合、人々は常に（lol）接頭辞を更新して変更を反映するのを忘れるか、意図的に更新しないでください。
• 「@g」としてコードの話を複雑にします 言いました：ハンガリー語表記の変数名は、一般的に発音しにくいアルファベットのスープです。これは、名前を「言う」ことができないため、読みやすさとコードの議論を妨げます。
• ...現時点では思い出せないことがたくさんあります。たぶん私は長い間、虐待されたハンガリー記法に対処する必要がないという喜びを持っていたので...

ハンガリー語表記は、現代のプログラミング環境でのアンチパターンの命名とトートロジーの形式です。

情報を無駄に繰り返し、利益も追加のメンテナンスオーバーヘッドもありません。のintような別の型に変更するとどうなりますか？longすべての変数の名前を変更するには、コードベース全体を検索および置換する必要があります。または、名前に型を複製しなかった場合よりも意味的に間違っています。

DRYの原則に違反しています。データベーステーブルにテーブルであることを思い出させるためにデータベーステーブルに略語のプレフィックスを付ける必要がある場合、テーブルを意味的に十分に説明的に命名しないことは間違いありません。これはあなたがこれをしている他のすべての事柄についても同じです。それは単なる追加のタイピングであり、最新の開発環境では利益も利益もありません。

ウィキペディアには、ハンガリー記法の長所と短所のリストがあるため、おそらくこの質問に対する最も包括的な答えを提供できます。注目すべきopinonsはまた、非常に興味深い読み込まれます。

ハンガリーの表記法を使用しないことの利点は、基本的にその欠点を回避することだけです。

• コンパイラによって型チェックが行われる場合、ハンガリーの表記法は冗長です。型チェックを提供する言語のコンパイラーは、変数の使用がその型と自動的に一致するようにします。目視によるチェックは冗長であり、人為的ミスの影響を受けます。

• すべての最新の統合開発環境は、要求に応じて変数タイプを表示し、互換性のないタイプを使用する操作に自動的にフラグを立て、表記法をほとんど廃止します。

• ハンガリーの表記法は、テーブルの主キーの一部である型のa_crszkvc30LastNameColデータベース列の内容を保持する定数参照引数のように、いくつかのプロパティを表すために使用すると混乱します。LastNamevarchar(30)

• コードが変更または移植されると、矛盾が生じる可能性があります。変数の型が変更された場合、変数の名前の装飾が新しい型と矛盾するか、変数の名前を変更する必要があります。特によく知られている例は、標準WPARAM型と、wParam多くのWindowsシステム関数宣言に付随する仮パラメーターです。「w」は「word」を表します。「word」はプラットフォームのハードウェアアーキテクチャのネイティブワードサイズです。元々は16ビットワードアーキテクチャでは16ビットタイプでしたが、32ビットワードアーキテクチャでは32ビットタイプに変更され、64ビットワードアーキテクチャでは64ビットタイプに変更されました。元の名前（真の基本型はUINT_PTR、つまり、ポインタを保持するのに十分な大きさの符号なし整数）。セマンティックインピーダンス、したがってプラットフォーム間のプラットフォームの混乱と矛盾は、「w」がこれらの異なる環境で16ビットを表すという前提に基づいています。

• ほとんどの場合、変数の使用を知ることは、その型を知ることを意味します。さらに、変数の使用法がわからない場合、その型から推測することはできません。

• ハンガリーの表記法は、プログラマーが最初に型指定子全体を入力する必要があるため、変数名の補完をサポートする機能豊富なコードエディターを使用する利点を大幅に減らします。

• 不必要な型とスコープのプレフィックスで変数の目的をわかりにくくすることで、コードを読みにくくします。

• 追加のタイプ情報では、より説明的な名前を十分に置き換えることができません。たとえばsDatabase、読者にそれが何であるかを伝えません。databaseNameよりわかりやすい名前になります。

• 名前が十分に説明的である場合、追加のタイプ情報は冗長になる可能性があります。たとえばfirstName、おそらく文字列です。したがって、名前をsFirstName付けると、コードが煩雑になります。

私自身はこの表記法を使用しません。なぜなら、不必要な技術的なノイズが嫌いだからです。私はどのタイプを扱っているかをほぼ常に知っており、ドメインモデルでクリーンな言語が必要ですが、ほとんど静的かつ強く型付けされた言語で記述しています。

MS SQL Server固有の問題として：

「sp_」で始まるストアドプロシージャは、作成されたものではなく、最初にMasterデータベースで検索されます。これにより、実行中のストアドプロシージャに遅延が発生します。

IMOハンガリー語を使用しないことの最大の利点は、意味のある名前を使用するように強制するという事実です。変数に適切な名前を付けている場合は、変数のタイプをすぐに把握するか、適切に設計されたシステムでかなり迅速に推定できる必要があります。変数のタイプを知るためにすべてのプレフィックスに依存するstrかbln、さらに悪いobj場合は、命名の問題を示していると思います-一般的には変数名が貧弱であるか、意味を伝えるには汎用的すぎるかのどちらかです。

皮肉なことに、私がハンガリー語で使用した主なシナリオは、個人的な経験から「カーゴカルト」プログラミング（つまり、他のコードが使用するため、そのまま使用し続けます）またはVB.NETで、言語が大文字と小文字を区別しPerson oPerson = new Personません（たとえば、使用できずPerson person = new Person、Person p = new Personあいまいすぎるため）。その特定のケースではPerson thePerson = new Person、代わりに（theまたはuglierのようにPerson myPerson = new Person）"the"または "my"の接頭辞も見ました。

ハンガリー語を使用するのは、ASP.NETコントロールの場合に限る傾向があるので、これを追加しますが、これは本当に選択の問題です。単純なを入力TextBoxCustomerNameするのCustomerNameTextBoxと比べると、非常にいのですtxtCustomerNameが、それでも「汚い」と感じます。同じデータを表示するコントロールが複数存在する可能性があるため、コントロールには何らかの命名規則を使用する必要があると感じています。

あなたが言及したので、SQL Serverに焦点を当てます。テーブルの前に「tbl」を配置する理由はありません。任意のtSQLコードを見て、使用方法によってテーブルを区別できます。UDFを使用したり、ストアドプロシージャを使用しSelect from stored_procedure.たりすることはありません。Select from table(with_param)Execute tblTableOrViewName

テーブルはビューと混同される可能性がありますが、使用方法に関しては、違いはないので、ポイントは何ですか？ハンガリー語の表記法を使用すると、SSMSで（テーブルまたはビューの下で）検索する時間を節約できますが、それだけです。

変数は問題を引き起こす可能性がありますが、変数を宣言する必要があります。実際、変数を使用することを宣言ステートメントからどれだけ遠ざけますか。数行のスクロールは、非常に長い手順を書かない限り、それほど大きな問題ではありません。長いコードを少し分割することをお勧めします。

あなたが説明するのは苦痛ですが、ハンガリー記法の解決策は実際には問題を解決しません。他の人のコードを見ると、変数の型が変更されている可能性があり、変数名を変更する必要があります。もう1つ忘れてください。そして、VarCharを使用する場合、サイズを知るためにとにかくdeclareステートメントを調べる必要があります。わかりやすい名前を付けると、おそらくさらに先に進みます。@PayPeriodStartDateは、それ自体をほとんど説明しています。

もう1つ追加するのは、.NETのようなフレームワーク全体でどの略語を使用するかということです。ええ、btnボタンとtxtテキストボックスを表すのはとても簡単です。しかし、次のようなことに対して何を念頭に置いていますStringBuilderか？strbld？どうCompositeWebControl？次のようなものを使用しますか？

CompositeWebControl comWCMyControl = new CompositeWebControl();

ハンガリーの表記法の非効率性の1つは、フレームワークがますます大きくなることにより、追加の利点が追加されるだけでなく、開発者がより多くの複雑さを追加することが証明されたことです。

私の物事の見方では、ハンガリー語表記法は、不十分に強力な型システムを回避するための手掛かりです。独自の型を定義できる言語では、期待する動作をエンコードする新しい型を作成するのは比較的簡単です。ハンガリー記法に関するJoel Spolskyの暴言で、彼は変数または関数が安全ではない（us）か安全であるかを示すことによってXSS攻撃の可能性を検出するためにそれを使用する例を示していますが、それでもプログラマーが視覚的にチェックすることに依存しています。代わりに拡張可能な型システムがある場合は、UnsafeStringとSafeStringの2つの新しい型を作成し、必要に応じて使用するだけです。ボーナスとして、エンコードのタイプは次のようになります。

SafeString encode(UnsafeString)

UnsafeStringの内部にアクセスしたり、他の変換関数を使用したりすることが、UnsafeStringからSafeStringに到達する唯一の方法になります。すべての出力関数がSafeStringのインスタンスのみを取る場合、エスケープされていない文字列を出力することができなくなります[StringToSafeString（someUnsafeString.ToString（））などの変換を伴うシェナンガンを除く）。

型システムにコードの健全性チェックを許可することが、手で、またはこの場合は目でそれを行うよりも優れている理由は明らかです。

Cなどの言語では、intはintであり、intはintであり、それについてできることはあまりありません。常に構造体を使用してゲームをプレイできますが、それが改善であるかどうかは議論の余地があります。

ハンガリー語表記の他の解釈については、IEは変数の型をプレフィックスとして使用しますが、これは単なる愚かであり、countOfPeopleのような意味のあるものの代わりに変数uivxwFooを命名するような怠laな慣行を奨励します。

ハンガリー語表記は、静的に型付けされた言語ではほとんど完全に役に立ちません。これは、マウスをその上に置くか、他の方法で変数のタイプを表示するための基本的なIDE機能です。さらに、型の推論がない場合は、宣言された場所を数行見て、型が何であるかを確認できます。型推論の要点はどこでも型のノイズを繰り返さないことです。そのため、ハンガリーの表記法は通常、型推論のある言語では悪いことと見なされます。

動的に型付けされた言語では、それは時々役立つことがありますが、私にとってはそれは一風変わった感じです。正確なドメイン/コドメインに制限されている機能を既に放棄しました。すべての変数の名前がハンガリー語表記である場合、型システムから得られるものを再現しているだけです。整数表記またはハンガリー表記の文字列にすることができる多態性変数をどのように表現しますか？「IntStringX」？「IntOrStringX」？私が今までハンガリーの表記法を使用した唯一の場所はアセンブリコードでした。これは、型システムがあった場合に得られるものを取り戻そうとしていたためであり、コード化した最初のコードでした。

とにかく、私は人々が彼らの変数に何を名付けるかをあまり気にすることができなかったでしょう、コードはおそらく同様に理解できないでしょう。開発者はスタイルや変数名などに時間を浪費しすぎますが、結局のところ、言語のまったく異なる慣習を備えた膨大な数のライブラリがまだ残っています。（：非テキストベースすなわち）は、変数名が存在しない言語、唯一のユニークな識別子、および変数の名前を示唆した（しかし、そこにあるため、ほとんどの変数はまだ提案された名前を持っていない私は、シンボリック開発しています単に存在しないための合理的な名前をそれら）; 信頼できないコードを監査する場合、変数名に依存することはできません。

そのような場合、いつものように、他の参加者からの回答を読む前に回答を投稿します。 

あなたのビジョンには3つの「バグ」があります。 

1）変数/パラメータ/属性/列のタイプを知りたい場合、マウスをホバーするかクリックすると、ほとんどの最新のIDEで表示されます。使用しているツールがわかりませんが、この機能を提供していない環境で作業することを強制されたのは20世紀で、言語はCOBOLでした。私が去った理由を理解していませんでした。 

2 /開発サイクル中にタイプが変更される場合があります。32ビット整数は、プロジェクトの開始時に検出されなかった正当な理由により、ある時点で64ビット整数になる場合があります。したがって、intXの名前をlongXに変更するか、間違った型を指す名前を付けたままにしておくのは悪いカルマです。 

3）あなたが求めているのは、実際には冗長性です。冗長性は、デザインパターンや習慣としてはあまり良くありません。人間でさえ、あまりにも多くの冗長性に消極的です。人間でさえ、あまりにも多くの冗長性に消極的です。 

ハンガリー人を切実に必要としていることは症状だと思う。グローバル変数
が多すぎるか、機能が長すぎて維持できないという症状。

通常、変数の定義が見えない場合、問題が発生します。
そして、もしあなたの関数が記憶に残る慣習に従わない場合、再び大きなトラブルが発生します。

それが...多くの職場がそれを打ち消している理由だと思います。

それはそれを必要とする言語に由来しました。 回では、グローバル変数の大当たり。（代替手段がないため） それは私たちによく役立ちました。

今日私たちが持っている唯一の本当の用途は、ジョエル・スポルスキーのものです。その安全性など、変数の特定の属性
を追跡するため。

（例えば、「変数にsafeFoobarはSQLクエリに挿入される緑色のライトがありますか？
—呼ばれているようにsafe、はい」）

他の回答の中には、変数にカーソルを合わせたときに変数の型を確認するのに役立つエディターの機能に関するものがあります。私の考えでは、これらもコードの健全性に問題があります。他の多くの機能（関数の折りたたみなど）と同様に、リファクタリングのみを目的としており、新しいコードでは使用しないでください。

ハンガリーの表記法を使用しない理由は、他のポスターでも十分に説明されていると思います。私は彼らのコメントに同意します。

データベースでは、コードではめったに使用されないが、そうでなければ名前空間で衝突するDDLオブジェクトにハンガリー語表記を使用します。主に、インデックスと名前付き制約の前にそのタイプ（PK、UK、FK、およびIN）を付けることになります。一貫した方法を使用してこれらのオブジェクトに名前を付けると、メタデータを照会することでいくつかの検証を実行できるはずです。

回避される理由は、ハンガリーのシステムがDRYに違反しているためです（プレフィックスは、コンパイラーと（良い）IDEが導出できるタイプです）

アプリハンガリー語OTOHは変数を使用してプレフィックスを付けます（つまり、scrxMouseは画面上のax座標です。これはint、short、long、またはカスタムタイプです（typedefsで簡単に変更することもできます））

システムの誤解がハンガリーをベストプラクティスとして破壊した

次のようなメソッドがあるとしましょう（C＃で）：

int GetCustomerCount()
{
    // some code
}

コードでは、次のように呼び出します。

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

int型は非常に私たちに教えてくれありません。何かがintであるという単なる事実は、その中身を教えてくれません。代わりに、次のように呼び出したとします。

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

これで、変数の目的がわかります。intであることがわかっている場合、問題になりますか？

ただし、ハンガリー語の本来の目的は、次のようなことをすることでした。

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

これは、cが何を表すかを知っている限り問題ありません。しかし、プレフィックスの標準テーブルが必要であり、誰もがそれらを知っている必要があり、新しい人々はあなたのコードを理解するためにそれらを学ぶ必要があります。一方、customerCountまたはcountOfCustomers一見するとかなり明白です。

Option Strict OnVB6以前では（およびVB .NETではOption Strict Off）VBは型を強制するため、ハンガリー語にはVBが存在する前に何らかの目的がありました。

Dim someText As String = "5"
customerCount = customerCount + someText

これは悪いことですが、コンパイラはそうは言いません。したがって、ハンガリー語を使用している場合は、少なくとも何が起こっているかの指標があります。

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

.NETでは、静的型付けでは、これは必要ありません。また、ハンガリー語は、適切なネーミングの代わりに頻繁に使用されていました。ハンガリー語を忘れて、代わりに良い名前を選んでください。

私は多くの良い議論を見つけましたが、私は見ていませんでした：人間工学。

以前は、string、int、bool、floatだけがあれば、sibfの文字で十分でした。しかし、string + shortでは、問題が始まります。プレフィックスに名前全体を使用しますか、または文字列にstr_nameを使用しますか？（ほとんどの場合、名前は文字列ですが、そうではありませんか？）Streetクラスとは何ですか？名前はますま​​す長くなり、CamelCaseを使用している場合でも、type-prefixがどこで終わり、variable-nameがどこで始まるかを見分けるのは困難です。

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

わかりました-下線を既に使用していない場合は下線を使用できます。下線を長く使用している場合はCamelCaseを使用できます。

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

それは怪物であり、あなたが結果的にそれを行う場合、あなたは持っています

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

ループ変数やのような些細な場合には、役に立たないプレフィックスを使用することになりますcount。最近、カウンターにショートまたはロングを使用したのはいつですか？例外を作成すると、多くの場合、プレフィックスが必要かどうかを考えて時間を失います。

多くの変数がある場合、通常はIDEの一部であるオブジェクトブラウザーにグループ化されます。40％がintのi_で始まり、40％が文字列のs_で始まり、アルファベット順にソートされている場合、名前の重要な部分を見つけるのは困難です。

ハンガリー語または類似の接尾辞を今でも定期的に使用している1つの場所は、同じ意味データがデータ変換のような2つの異なる形式で存在するコンテキストです。これは、複数の測定単位がある場合、または複数の形式がある場合（たとえば、文字列 "123"および整数123）にあります。

ハンガリー語を他の人に押し付けないことは説得力がありますが、あなた自身の実践を決定するために軽度の示唆に過ぎないため、ここでそれを使用しない理由を見つけました。

プログラムのソースコードは、それ自体がユーザーインターフェイスであり、メンテナーにアルゴリズムとメタデータを表示します。ユーザーインターフェイスの冗長性は、罪ではなく美徳です。たとえば、「日常的なもののデザイン」の写真を参照してください。「プッシュ」というラベルの付いたドアを見てください。 IDEでそれらは十分ではありませんでした。

「ただIDEにホバー」ではない唯一の理由-ハンガリー語は使用しない理由は、いくつかの人々は、それは便利ではないかもしれません。走行距離は異なる場合があります。

ハンガリー人が変数の型を変更するときに大きなメンテナンスの負担を課すという考えはばかげています-変数の型をどのくらいの頻度で変更しますか？また、変数の名前変更は簡単です。

IDEを使用して、発生するすべての名前を変更します。 -ガンダー、グースに返信

ハンガリー語が本当にコードの一部を素早く調べて確実に維持するのを助けてくれるなら、それを使ってください。そうでない場合は、しないでください。あなたがあなた自身の経験について間違っていると他の人があなたに言うならば、私は彼らがおそらく間違いのある人であることを提案するでしょう。