web-dev-qa-db-ja.com

C＃GUI命名規則のベストプラクティスですか？

GUIは、WinFormsまたはXAMLのどちらで作成されたものであっても、私が見るプロジェクト間で最も大きく異なる命名規則を持っているようです。人の名前の簡単なTextBoxには、さまざまな命名規則があります。

TextBox tbName      // Hungarian notation
TextBox txtName     // Alternative Hungarian
TextBox NameTextBox // Not even camelCase
TextBox nameTextBox // Field after field with TextBox on the end
TextBox TextBoxName // Suggested in an answer...
TextBox textBoxName // Suggested in an answer...
TextBox uxName      // Suggested in an answer...
TextBox name        // Deceptive since you need name.Text to get the real value
TextBox textBox1    // Default name, as bad as you can get

私は通常、すべての.csファイルのStyleCopルールを順守し、他のユーザーも同様にそれを行うことを確認しますが、GUIはこれらのルールを破る、または大きく異なる傾向があります。通常の変数の代わりにGUI要素を具体的に参照するMicrosoftのガイドラインや、コンソールアプリケーションの外部に適用される例を見たことはありません。

GUIで要素に名前を付けるためのベストプラクティスは何ですか？

c#winformsuser-interfacenaming-conventions
68
Will Eddins

私は古い学校のハンガリー語を使用しています... TextBoxにはtxt、Buttonにはbtnを使用し、続いて一般化されたWord、さらに具体的なWordを使用します。すなわち：

btnUserEmail

「」というようなことを多くの人に言わせたことがあります。「非常に古い、VB6呼び出しです！」しかし、UI Rich winformsアプリでは、検索して変更できます通常、コントロールについて最初に知っているのは、タイプ、次にカテゴリ、そして具体的になることです。新しいスタイルの命名規則では、テキストボックスの名前を覚えようとしています。

コントロールの元の仕様はこちら（アーカイブ済み）です。

74
Neil N

私が使う：

TextBox nameTextBox;

私が使用するのと同じように：

MailAddress homeAddress;

その理由は、これらの場合、「TextBox」と「Address」はオブジェクトの格納方法や使用方法ではなく、オブジェクトが表すものを説明するためです。しかし、人のフルネームを保存するような別のケースでは、次を使用します。

string fullName;

しない：

string fullNameString;

「文字列」はオブジェクトが表すものを説明するものではなく、保存方法のみを説明するものです。

29
Lee

.NETの他のすべてと同じ規則：キャメルケースの説明的な名前のみ。オプションで、同じ論理「もの」に対して異なるクラスを区別する必要がある場合は接尾辞が続きます。例えば：

string name; // a name
TextBox nameText; // the control used to edit the name
Label nameLabel; // the control used to label the edit control
List<string> nameList; // a list of names

無限に続きます。接尾辞が一貫性があり説明的なものである限り、接尾辞が何であるかは実際には関係ありません。

12
Christian Hayter

これは私の発明ではありませんが、私はそれが好きです：

TextBox uxName = new TextBox();
Label uxNameLabel = new Label();
Button uxAccept = new Button();

私のすべてのUIコントロールがインテリセンスで1つのブロックに表示されるため、ハンガリー語表記よりもこれを好みます。 「ユーザーエクスペリエンス」のUX。また、コントロールをテキストボックスからコンボボックスなどに変更しても、名前は変わらないので便利です。

9
Brandon

誰かがこの主題の権威になり、それをそのように伝え、それを強制し始めることを望みます...私にとって最悪のことは、人々がそれを同じアプリケーションまたはさらに悪いがさらに同じクラスで混同することです。

TxtName、NameTextBox、name、およびtextBox1がすべて同じフォームで使用されている、かなり恐ろしいものがいくつかあります。

私が働いている場所には、それを行う方法、それを行う場所を示す標準文書があります。

Fxcopが私に怒鳴ったら、私は通常何かを変えます。

http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29

大文字のスタイル

注：Microsoft .NETでは、ほとんどの識別子にUpperCamelCase（別名「パスカルスタイル」）を推奨しています。 （lowerCamelCaseはパラメーターに推奨されます）。

4
zimmer62

命名規則について最も重要なことは、意味のあるものを選択し、すべての関係者からコンセンサスを得て、あなたの人生がそれに依存しているように固執することです。

どの規約を使用するかについては、私はこれに投票します：

TextBox name

これは短く、識別子として意味的な値を持っています。識別子のtypeに関しては、Visual Studioを使用して、そのようなことが得意である傾向があることを伝えます。

3
Andrew Hare

Hungation表記を使用しますが、少し違いがあります。

私は今、非常にリッチなUIを持つプロジェクトに取り組んでいます。したがって、IntelliSenseを使用して、たとえばbtnGetUsersというボタンを見つけるのは非常に簡単です。

アプリケーションがさまざまな場所からユーザーを取得できる場合、事態は複雑になります。それは異なるコントロールです。それで、私はコントロールが配置された場所にちなんでコントロールに名前を付け始めましたが、それでもハンガリーの表記法を使用しています。

例として：tabSchedAddSchedTxbAdressは、txbAddressがアドレスを挿入できるテキストボックスであり、Scheduling Tab ControlのAdd Schedulingタブにあることを意味します。これにより、コントロールを非常に簡単に見つけることができ、単に「btn」と入力しても、ユーザーインターフェイス全体から多くのボタンを一度に取得できません。

もちろん、これは自分自身を助けるためだけです。私はそのようなベストプラクティスを知りません。しかし、それは大いに役立ちます。

もす

3
mosu

すべてのUI要素にTypeDescriptorという名前を付けます。あなたの例に従って、TextBoxName。

2
Matt Grande

私はc_typeNameを使用する傾向があります（タイプと名前が異なることに注意してください）、例えばユーザーが電子メールを入力するTextBoxのc_tbUserEmail。コントロールがたくさんある場合、数マイルのインテリセンスリストで見つけるのが難しいので、c_プレフィックスを追加することで、そのフォームのすべてのコントロールを簡単に見ることができるので便利です。

2
ShdNx

私は最近、MFC（6.0 ...）から移行しているチームと協力しています。そこでは

CString Name;
CEdit ctlName;

移行する最も簡単な方法は、次のようなものを使用することです

TextBox ctlName

変数がコントロールであり、コントロールの値ではないことを思い出してください。

名前の一部としてタイプを含めることは、ただ古いと思います。

-編集-もう1つの利点は、操作時にすべてのコントロールがグループ化されることです。実際のタイプが使用された場合、ComboBoxコントロールはTextBoxコントロールからかなり遠くなります。

2
Brad Bruce

このハンガリー語/ VB6命名の狂気はやめる必要があります。

Microsoftが本当にタイプに基づいてコントロールに名前を付けたい場合、Visual StudioがWeb/Winフォームにコントロールを追加するときに「txt」または「btn」を自動的に付加しないのはなぜですか？

2
Craig

私自身のプラクティスは、タイプ_contextDescriptionTypeです。例えば。：

TextBox _searchValueTextBox

とにかく、命名規則は個人的なものであるか、一般的な規則によって課されています。いずれにしても、プロジェクト開発者全員が簡単にアクセスできるように、どこかに文書化する必要があります。

1
terR0Q

マイクロソフトの 名前のガイドライン があります。私はすべてに続くわけではありませんが、それは良い出発点です

1
Gabriel Mongeon

開発者のコ​​ーディング作業を容易にし、管理しやすくするために命名規則が存在すると考えています。私の理解では、簡単にアクセスするのに役立つ任意の名前に従う必要があります。

私はさまざまなアプローチで多くのコメントを見ましたが、私のプロジェクトで見つけた最高の方法は、コントロールの最初の3つの名前にプレフィックスを付けることです。このアプローチに従うことの背後には多くの理由があります。

  1. Intellisenseは、すべて同じタイプをまとめます。
  2. フォームプロパティウィンドウにも同じコントロールがすべて表示されます。
  3. 複雑なフォームでは、ラベルまたはテキストボックスを扱っているかどうかを簡単に識別できます（例：lblAccountsおよびtxtAccounts）
  4. 新しいユーザーはコーディングを簡単に処理できます。
  5. 同じフォームにaccountLst、accountlbl、accounttxt、accountgrd、accountChkコントロールがあるとします。

コーディング中、開発者はテキストボックスまたはラベルにアクセスしていることを常に認識しています。彼が他の開発者が使用した名前を明確にしていない場合。したがって、「lbl」インテリセンスを記述するだけで、選択するすべてのラベルリストが表示されます。＃5で使用したアプローチを使用した場合、intellisenseはaccを使用してすべてのコントロールを表示します。 「account」などで始まるコントロール名でループを実行することはほとんどありませんでした。これは、まれなインシデントでは役に立たないことを意味します。

私の賭けは、他の開発者がコードを簡単に理解できるようにすることです。あなたがキャリアで成長するにつれて、あなたはいつもコーディングをするわけではないので、他の誰かがあなたの席に着くでしょう。

選択肢はあなた次第です。

1
Rohit.Net

ハンガリー語の表記法を使用しています。これにより、大きなページでコントロールを見つけやすくなります。

1
Cleiton

コードで使用する予定のない要素については、デザイナーに処理を任せます。それらが私のコードで使用されるものになると、意味のあるものに変更され、たまたまdescriptionType（nameTextBox）になります。十分な情報が与えられた場合、デザイナーがそれらを作成する方法です（メニュー項目をチェックしてください-「終了」はexitMenuItemになります）。

1
Austin Salonen

アプリケーションの設計で懸念事項が適切に分離されている場合、LoginButton、LoginBtn、またはbtnLoginとしてボタンに名前を付ける必要はないと思います。オブジェクトの所有者がUI要素である場合、ログインと呼びましょう。所有者がUI要素でない場合、オブジェクトは間違った場所にあります。

0
Dr Jack