conventions - 人々は現実世界でハンガリーの命名規則を使用していますか?

Question

慣習を学ぶ価値はありますか、それとも可読性と保守性を損なうものですか?

score 59 · Accepted Answer

ハンガリー記法を使用しているほとんどの人が誤解されたバージョンに従っていることを考えると、それはかなり無意味だと思います.

元の定義を使用したい場合は、より理にかなっているかもしれませんが、それ以外はほとんどが構文糖衣です。

この件に関するウィキペディアの記事を読むと、2 つの矛盾する表記法、Systems Hungarian NotationとApps Hungarian Notationが見つかります。

元の適切な定義はApps Hungarian Notationですが、ほとんどの人はSystems Hungarian Notationを使用しています。

2 つの例として、長さを表す l、面積を表す a、体積を表す v を変数の前に付けるとします。

このような表記法を使用すると、次の式が意味を成します。

int vBox = aBottom * lVerticalSide;

しかし、これはしません:

int aBottom = lSide1;

接頭辞を混在させている場合、それらは方程式の一部と見なされます。体積 = 面積 * 長さはボックスでは問題ありませんが、長さの値を面積変数にコピーすると、危険信号が発生するはずです。

残念ながら、次のように変数名の前に値の型を付ける他の表記法はあまり役に立ちません。

int iLength;
int iVolume;
int iArea;

数値に n、整数に i、float に f、文字列に s などを使用する人もいます。

元の接頭辞は、方程式の問題を見つけるために使用されることを意図していましたが、変数宣言を探す必要がないため、コードが少し読みやすくなるようになりました。今日のスマートエディターでは、任意の変数にカーソルを合わせるだけで完全な型を見つけることができ、単なる省略形ではないため、このタイプのハンガリー語表記はその意味の多くを失いました。

しかし、あなたは自分の心を決めるべきです。私が言えることは、どちらも使用しないということだけです。

編集短い通知を追加するために、私はHungarian Notationを使用していませんが、接頭辞を使用しています。それはアンダースコアです。クラスのすべてのプライベートフィールドの前に _ を付け、それ以外の場合はプロパティと同じように名前を綴ります。最初の文字は大文字です。

score 22 · Accepted Answer

ハンガリアン記法は、正しく使用すると便利ですが、残念ながら、誤用されることがよくあります。

適切な見方と正当性については、JoelSpolskyの記事「間違ったコードを間違って見えるようにする」を読んでください。

基本的に、変数の前に型に関する情報（オブジェクトが文字列、ハンドル、整数など）である、型ベースのハンガリアン記法はほとんど役に立たず、一般にオーバーヘッドを追加するだけで、ほとんどメリットがありません。悲しいことに、これはほとんどの人がよく知っているハンガリアン記法です。ただし、想定されるハンガリアン記法の目的は、変数に含まれるデータの「種類」に関する情報を追加することです。これにより、ある種のデータを他の種類のデータから分割することができます。他の種類のデータは、おそらく何らかの変換プロセスを介する場合を除いて、一緒に混合することはできません。たとえば、ピクセルベースの座標と他の単位の座標、または安全でないユーザー入力と安全なソースからのデータなどです。

このように見てください。変数に関する情報を見つけるためにコードを調べていることに気付いた場合は、おそらくその情報を含むように命名スキームを調整する必要があります。これがハンガリーの慣習の本質です。

ハンガリアン記法の代わりに、どこでもプリミティブ型に依存するのではなく、より多くのクラスを使用して変数の使用目的を示すことに注意してください。たとえば、安全でないユーザー入力用の変数プレフィックスを使用する代わりに、安全でないユーザー入力用の単純な文字列ラッパークラスと、安全なデータ用の個別のラッパークラスを使用できます。これには、強く型付けされた言語では、コンパイラーによってパーティション化が適用されるという利点があります（あまり強く型付けされていない言語でも、通常は独自のトリップワイヤーコードを追加できます）が、それほど重要ではないオーバーヘッドが追加されます。

score 14 · Accepted Answer

UI 要素に関しては、今でもハンガリー記法を使用しています。いくつかの UI 要素が特定のオブジェクト/値に関連しています。

ラベルオブジェクトの lblFirstName、テキストボックスの txtFirstName。それが両方のオブジェクトの懸念/責任であっても、両方に「FirstName」という名前を付けることは絶対にできません。

他のユーザーは、UI 要素の命名にどのように取り組んでいますか?

score 11 · Accepted Answer

ハンガリアン記法は、より読みやすいコードへの「パス」に沿った興味深い脚注であり、適切に行われた場合は、行わないよりも望ましいと思います。

とはいえ、私はむしろそれを廃止したいと思います、そしてこれの代わりに：

int vBox = aBottom * lVerticalSide;

これを書く：

int boxVolume = bottomArea * verticalHeight;

2008年です。80文字の固定幅画面はもうありません。

また、それよりもはるかに長い変数名を記述している場合は、とにかくオブジェクトまたは関数へのリファクタリングを検討する必要があります。

score 9 · Accepted Answer

それは無意味です（そして気が散る）が、少なくともint、strings、booleans、doublesのようなタイプでは、私の会社で比較的頻繁に使用されています。

、、、、など、sValueどこにでもiCountあります。dAmountfAmountbFlag

昔々、この大会には正当な理由がありました。今、それは癌です。

score 5 · Accepted Answer

質問を続けて申し訳ありませんが、インターフェースに「I」というプレフィックスを付けることは、ハンガリー語表記と見なされますか? もしそうなら、はい、多くの人が現実の世界でそれを使用しています. そうでない場合は、これを無視してください。

score 5 · Accepted Answer

ハンガリー記譜法は、短期記憶の容量を回避する方法だと思います。心理学者によると、約7 プラスマイナス 2 チャンクの情報を保存できます。プレフィックスを含めることによって追加される追加情報は、他のコンテキストがなくても、識別子の意味に関する詳細を提供するのに役立ちます。つまり、変数がどのように使用または宣言されているかを見なくても、その変数が何のためにあるのかを推測できます。これは、カプセル化や単一責任の原則などの技術を適用することで回避できます。

これが経験的に研究されているかどうかはわかりません。9 つを超えるインスタンス変数を持つクラスまたは 9 つを超えるローカル変数を持つメソッドを理解しようとすると、労力が劇的に増加すると仮定します。

score 4 · Accepted Answer

ハンガリー語の議論を見ると、コードをより明確にする方法や、間違いをより目立たせる方法について人々が真剣に考えているのを見ることができてうれしいです。それはまさに私たち全員がすべきことです！

ただし、名前を付ける以外に、強力なツールを自由に使用できることを忘れないでください。

メソッドの抽出メソッドが長くなりすぎて変数宣言が画面の上部からスクロールアウトした場合は、メソッドを小さくすることを検討してください。（メソッドが多すぎる場合は、新しいクラスを検討してください。）

厳密な型指定整数変数に格納されている郵便番号を取得し、それらを靴のサイズの整数変数に割り当てる場合は、郵便番号のクラスと靴のサイズのクラスを作成することを検討してください。そうすれば、人間による注意深い検査を必要とせずに、コンパイル時にバグが検出されます。これを行うと、通常、郵便番号と靴のサイズに固有のロジックがたくさん見つかります。これらのロジックをコードの周りに配置して、新しいクラスに移動できます。突然、私のすべてのコードがより明確に、より単純になり、特定のクラスのバグから保護されるようになりました。わお。

要約すると、はい、コードで名前を使用してアイデアを明確に表現する方法についてよく考えてください。また、呼び出すことができる他の強力なOOツールにも注目してください。

score 4 · Accepted Answer

最近はタイプよりもスコープの方が重要ではありませんか？

l ローカル
引数の a
メンバーのm
グローバルの g
等

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

score 2 · Accepted Answer

私は厳密な意味でハンガリー語表記法を使用していませんが、いくつかの一般的なカスタムオブジェクトを識別しやすくするために、ハンガリー語表記法を使用していることに気付きました。たとえば、labelFirstName、textFirstName、buttonSubmit などです。

score 1 · Accepted Answer

動的型付け言語を使用する場合、AppsHungarianを使用することがあります。静的に型付けされた言語の場合、私はしません。他のスレッドの私の説明を参照してください。

score 1 · Accepted Answer

何が問題なのかは、標準の混合です。

正しいのは、全員が同じことをするようにすることです。

int Box = iBottom * nVerticleSide

score 1 · Accepted Answer

ボタン、テキストボックス、ラベルなどの UI 要素にはハンガリー語の命名規則を使用しています。主な利点は、Visual Studio Intellisense ポップアップでのグループ化です。自分のラベルにアクセスしたい場合は、単に lbl.... と入力し始めるだけで、Visual Studio はすべてのラベルを nicley グループにまとめて提案します。

しかし、Silverlight と WPF の処理をどんどん行って、データバインディングを活用するようになったので、コードビハインドからコントロールを参照する必要がなくなったので (実際にはコードビハインドがなくなったので)、すべてのコントロールに名前を付けることさえしなくなりました。 ;)

score 1 · Accepted Answer

タイプセーフな言語では、ハンガリー語表記は無意味です。たとえば、古い Microsoft コードで見られる一般的なプレフィックスは "lpsz" で、これは "ゼロで終わる文字列への長いポインター" を意味します。1700 年代初頭以来、短いポインタと長いポインタが存在するセグメント化されたアーキテクチャは使用していません。C++ の通常の文字列表現は常にゼロで終了し、コンパイラはタイプセーフであるため、文字列以外の操作をストリング。したがって、この情報はプログラマーにとって実際には何の役にも立ちません。

しかし、私は同様の考え方を使用しています:変数の使用法を明確にする接頭辞です。主なものは次のとおりです。

m = メンバー
c = 定数
s = 静的
v = 揮発性
p = ポインター (および pp = ポインターへのポインターなど)
i = インデックスまたは反復子

これらは組み合わせることができるため、ポインターである静的メンバー変数は「mspName」になります。

これらはどこで役に立ちますか?

使用法が重要な場合は、変数が (たとえば) volatile またはポインターであることを常にプログラマーに思い出させることをお勧めします。
p プレフィックスを使用するまでは、ポインターの逆参照が頭を悩ませていました。これで、オブジェクト (Orange)、オブジェクトへのポインター (pOrange)、またはオブジェクトへのポインター (ppOrange) へのポインターがあるかどうかを簡単に知ることができます。オブジェクトを逆参照するには、その名前の各 p の前にアスタリスクを付けます。ケースが解決され、deref バグはもうありません!
コンストラクターでは、通常、パラメーター名がメンバー変数の名前 (サイズなど) と同じであることがわかります。「mSize = size;」を使用することを好みます。「size = theSize」または「this.size = size」よりも。また、はるかに安全です。「mSize = 1」（メンバーの設定）と言うつもりだったときに、誤って「size = 1」（パラメーターの設定）を使用することはありません。
ループでは、イテレータ変数はすべて意味のある名前です。ほとんどのプログラマーは "i" または "index" を使用し、内部ループが必要な場合は新しい無意味な名前 ("j"、"index2") を作成する必要があります。i プレフィックス (iHospital、iWard、iPatient) を付けた意味のある名前を使用するので、反復子が何を反復しているかを常に把握できます。
ループでは、同じ基本名に異なる接頭辞を付けて使用することで、いくつかの関連する変数を混在させることができます。これは、配列のインデックス付けエラーを起こさないことも意味します (pApple[i] は問題ないように見えますが、pApple[iOrange] と書くと、エラーはすぐにわかります)。
多くのプログラマーは私のシステムを知らずに使用します: "Index" や "Ptr" のような長い接尾辞を追加することで、1 文字よりも長い形式を使用する正当な理由がないので、"i" と " p」。タイピングが減り、一貫性が増し、読みやすくなります。

これは、有意義で有用な情報をコードに追加し、多くの単純だが一般的なプログラミングの誤りの可能性を排除する単純なシステムです。

score 1 · Accepted Answer

元の接頭辞は、方程式の問題を見つけるために使用されることを意図していましたが、変数宣言を探す必要がないため、コードが少し読みやすくなるようになりました。今日のスマートエディターでは、任意の変数にカーソルを合わせるだけで完全な型を見つけることができ、単なる省略形ではないため、このタイプのハンガリー語表記はその意味の多くを失いました。

私はその習慣を少し破っていますが、型のプレフィックスを付けることは、強力な変数の型指定を持たない JavaScript で役立つ場合があります。

score 0 · Accepted Answer

それはあなたの言語と環境に依存します。原則として、使用している開発環境で変数の型を見つけるのが難しい場合を除いて、私はそれを使用しません。

ハンガリアン記法には2つの異なるタイプもあります。Joelの記事を参照してください。私はそれを見つけることができません（彼の名前はそれらを見つけるのを正確に簡単にするわけではありません）、誰かが私が意味するものへのリンクを持っていますか？

編集：ウェッジは彼の投稿で私が意味する記事を持っています。

score 0 · Accepted Answer

元の形式 (右ハンガリー記法 :) ) の接頭辞は、変数によって格納される値のタイプ (つまり、長さ、量) を意味しますが、すべてのタイプのアプリケーションで必要というわけではありません。

接頭辞が型 (String, int) を意味する一般的な形式 (間違ったハンガリー表記法) は、ほとんどの最新のプログラミング言語では役に立ちません。

特に、strA のような意味のない名前では。私たち人間が意味のない名前に長い接頭辞をつけて何の役にも立たないものを使っていることが理解できません。

score 0 · Accepted Answer

私は過去 6 か月間 IBM で働いていますが、どこにも見たことがありません (私はそれが嫌いなので、神に感謝します)。

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

score 0 · Accepted Answer

オートコンプリートの動作を改善するため、コンポーネント (editFirstName、lblStatus など) にタイプベース (Systems HN) を使用します。

型情報が十分な変数には App HN を使用することがあります。つまり、fpX は、固定されたポインター変数 (int 型ですが、int と混合して一致させることはできません)、検証されていないユーザー文字列の rawInput などを示します。

score 0 · Accepted Answer

型付けが非常に緩いPHPプログラマであるため、私はそれを使用することを強調していません。ただし、システムのサイズと変数のスコープに応じて、何かを配列またはオブジェクトとして識別することがあります。

conventions - 人々は現実世界でハンガリーの命名規則を使用していますか?

20 に答える 20

Related

Reference