ハンガリー語表記を使用しないように苦労している


10

Systems Hungarianに対する賛否両論があります。数年間、私はすべての変数に名前を付けてこのシステムを使用するレガシープロジェクトに取り組んできました。たとえば、(strName、intAge、btnSubmitなどの)変数タイプのプレフィックスを付けます(元のハンガリーアプリのプレフィックスは型ではなく変数)。次のプロジェクトではそれを完全に破棄したいのですが、それに頼らずに同じようなものに一意の名前を付けるのは難しいと思います。

メールアドレスを収集してデータベーステーブルに保存するためのウェブフォームと、アドレスをデータベースに保存する関数を呼び出すボタンがあるとします。

ハンガリースタイルの表記法を使用している場合、ボックスをtxtEmailボタンbtnEmail、テキストボックスに含まれる値と呼ぶことができますstrEmail。次に、関数storeEmail(strEmail)を使用してメールを保存します。ここには明確な規則があります。各変数が何であるかは明らかです。

これらの変数に名前を付けるためのベストプラクティスは何でしょうか

  • ハンガリーのシステムに頼ることなく
  • それらを長くしたり混乱させたりすることなく
  • プロジェクト全体で使用する明確な規則がありますか?

2
一意の名前を見つけるのに問題がある場合は、残りの命名規則や関数のサイズに何か問題がある可能性があります。

どのテクノロジーを使用していますか?これらのプレフィックスは、Webフォームに適しているようです。
StuperUser

私はASP.NETを使用しています(C#は後ろにあります)
fearoffours '

@delnan-詳しく説明していただけますか?関数サイズにより、命名が一意に簡単になるのはなぜですか?
fearoffours

@fearofours:関数が小さいほど、必要な変数が少なくなり、変数が少ないほど、変数の衝突が少なくなります。もちろん、すべての変数を可能な限り小さなスコープに配置することを前提としています。

回答:


8

最後のポイントが最も重要です。プロジェクト全体で、また同僚と一貫性を保つために必要なことは何でも。一貫性を実現するには主に2つの方法があり、可能であれば両方を使用する必要があります。まず、ツールを使用して、ビルド時に命名規則を確認します。.Netの世界では、StyleCopがそのようなツールの良い例です。一貫性を確保するための2番目の方法は、すべてのコードのピアレビューを行うことです。

あなたの他の2つのポイントは代替案について尋ねているようです。代替案が必要かどうかはわかりません。ハンガリー語の人気がなくなった点は、型システムとツールが少し厳しかったときに型を説明するために使用されていたことです。つまり、Cでプログラミングしていて、型を追跡する唯一の方法でポインタを渡す場合は、ハンガリー語を使用することでした。これで、C#やJavaなどの言語を使用している場合は、ポインターを使用しないため(または、ごくまれに)、ハンガリー語の必要性がなくなります。また、最近のIDEでは、変数にカーソルを合わせるか、最悪の場合はショートカットを使用して元の宣言を表示することで、型を非常に簡単に確認できます。だから、私はあなたがどんな種類の表記も必要とは思わない、それが何をするかによって変数に名前を付けるだけです。メールアドレスの場合は、「email」または「


2
フォーム/ページ/ウィンドウ/何でもメール用のボタン、メール用のテキストボックス、そしておそらくメール用の別のウィジェット/コントロールがある場合、少しトリッキーになります...
FrustratedWithFormsDesigner

7
@FrustratedWithFormsDesigner必ずしもそうとは限りません。テキストボックスはemailAddressInputで、ボタンはemailAddressSubmitで、内部表現は単なるemailAddressです。
ジョナサン

@ジョナサン:良い点。
FrustratedWithFormsDesigner

3

Webフォーム、Windowsフォーム、その他のグラフィカルなものを扱う場合、テキストボックスとラベルが一緒に結合されるなど、非常に緊密に結び付けられたコントロールを使用できるため、システムハンガリー語を使用することは理にかなっています。あなたはそれらに名前を付けるかもしれないtxtEmailし、lblEmailそれらを区別するために。私の経験では、これは一般的で実際に役立ちます。

ただし、コードビハインドでは、この種の命名は不要です。stringメールの保存に使用されている型の変数がある場合は、名前を付けemailます。なんらかの理由で混乱した場合、ほとんどのIDEでは、カーソルを合わせてそのタイプを確認できます。(理想的には、オブジェクト指向の場合、オブジェクトの属性である可能性があり、user.Emailさらに明確になります。)

email正しく名前が付けられている可能性があるGUIコントロールではないコードで宣言されているオブジェクトが複数ある場合は、設計に本質的に何か問題があると思います。


1
実際にはtxtとlblはハンガリー語ではなく、txtはテキストの短いテキストであり、lblはラベルの略です。フォームでEmailTextやEmailLabelなどの完全な単語を使用しない理由はありません。ハンガリー語がタイプになります。どちらの場合も文字列です。
Steve

1
@Steve Haigh-いいえ、私はコントロール自体について話しています。txtEmailと呼ばれるタイプ「textbox」のオブジェクトとlblEmailと呼ばれるタイプ「label」のオブジェクトがあります。どちらも文字列ではありません。それら文字列プロパティを持っているかもしれませんが、それ自体は文字列ではありません。
Andrew Arnold

1
あ、ごめんなさい。はい、もちろん。それでも、EmailTextBoxなどのわかりやすい名前を使用しない理由はありません。VSが不適切な名前を生成するからといって、それを維持する必要があるわけではありません。ただし、フォームのコンテキストでは、txtとlblの省略形は非常によく理解されているので、おそらくその場合は心配しません。
スティーブ

3

変数を「長い間」にするものは何ですか?

代わりにtxtEmailbtnEmailあなたが使用することができUserEmailTextUserEmailButtonおよびAdminEmailTextAdminEmailButton

これに関する問題は、変数が長くなり始めていると感じ始める可能性があることです。

AdminEmailIsValid 変数を許可する期間の境界線を開始します。

さらに、一連の変数とそれらの変数に対する一連の操作を再利用していることに気付くかもしれません。これがOOPの設計です。一連の変数の代わりに、汎用オブジェクトを作成します。

class EmailForm
  var textBox, button, text
  function storeEmail()

次に、新しい変数をクラスとしてインスタンス化し、同じドット表記を使用してデータにアクセスできます。

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

もちろん、これはOOPパラダイムを使用する言語を対象としていますが、人気のあるWeb開発言語の大部分はオブジェクト指向であるか、オブジェクト指向コード(PHP、Python、C#、C ++、Java、JavaScript、ActionScriptなど)に対応しています)。


UserEmailTextのtxtEmailに対する利点を確認できませんでした。型のプレフィックスを付けるのではなく、接尾辞を付けるだけです。私は「これがOOPの設計目的です」が好きです。
fearoffours

@fearoffours、一意の名前の問題を有することを認めたOPは、私は2つの類似の変数(区別する記述方法として、その一例を添加UserEmailTextし、AdminEmailText特異的に)。必要な抽象化/機能性に応じて、クラスに移動するのに適したタイプの接尾辞を通常UserEmailText-> UserEmail.text-> User.email.text付けます。
zzzzBov

どこから来ているのか見てみましょう。接尾辞/クラスの比較のための+1。ああ、私はOPです!
fearoffours

@ fearoffours、lolおっと...
zzzzBov
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.