web-dev-qa-db-ja.com

WPFUI要素の命名規則

ハンガリアン記法 は今日では悪い習慣と見なされていますが、ユーザーインターフェイス要素の名前で型をエンコードすることは依然として非常に一般的です、プレフィックス（lblTitle、txtFirstName、...）またはサフィックス（TitleLabel、FirstNameTextBox、...）のいずれかを使用します。

私の会社でもこれを行っています。同僚が（またはずっと前に自分で）書いたコードが（私の経験では）読みやすくなるからです。 UI要素のタイプを変更するには、通常、コードのすべての部分を書き直す必要があるため、これを行うことに対して通常提起される引数（タイプが変更された場合は変数の名前を変更する必要があります）はそれほど強力ではありません。 。

したがって、WPF開発を開始するときは、この方法を維持することを考えています（うーん... TextBlocksまたはTextBoxesにtxtプレフィックスを使用する必要がありますか？）。私が見逃した大きな欠点はありますか？これは、「これをしないでください。なぜなら...」と言うチャンスです。

編集：データバインディングを使用すると、UI要素に名前を付ける必要性が減少することを私は知っています。それにもかかわらず、それは時々必要です、例えば。カスタムコントロールを開発するとき...

wpfcoding-style
29
Heinzi

個人的には、WPFがこれに関してルールを変更していることがわかりました。多くの場合、コードをほとんどまたはまったく使用せずに済ませることができるため、名前を区別するためのプレフィックスを付けると、混乱が少なくなるのではなく、混乱しやすくなります。

Windowsフォームでは、すべてのコントロールはコード内で名前で参照されていました。 UIが大きいので、半ハンガリアン記法が便利でした。作業しているものを区別するのが簡単でした。

ただし、WPFでは、名前が必要なのはまれなコントロールです。コードを介してコントロールにアクセスする必要がある場合は、添付のプロパティまたは動作を使用してアクセスするのが最適な場合がよくあります。その場合、複数のコントロールを処理することはありません。 UserControlまたはWindowコードビハインドで作業している場合は、「txtTitle」の代わりに「Title」と「Name」を使用します。特に、これからは、おそらく少数の制限されたコントロールのみを処理することになります。それらすべての。

ほとんどの場合、カスタムコントロールでさえ名前を必要としないはずです。慣例に従ったテンプレート名（つまり、PART_Name）が必要ですが、UIの実際のx：Name要素は必要ありません...

31
Reed Copsey

私の経験では-WPFでは、コントロールの種類を変更するときに、何か間違ったことをしない限り、通常はコードを書き直す必要はありません。実際、ほとんどの場合、コードでコントロールを参照することはありません。はい、最終的にはそれを実行しますが、WPFのUI要素への参照の大部分は、同じXAML内の他の要素によるものです。

そして個人的には、「lblTitle、lblCompany、txtFirstName」は「Title」よりも読みにくいと思います。 .intWidthと.intHeight（さようならlpzstrName！）がありません。なぜ.lblFirstNameがあるのですか？ TitleFieldやTitleInputなど、方法ではなく内容を説明しているので、もっと理解できます。

私にとって、このタイプの分離を希望するということは、通常、UIコードがやりすぎを意味します。もちろん、UI要素を処理しているので、ウィンドウコード内にあります。 UI要素の周りのコードを扱っていないのなら、なぜここでコーディングするのでしょうか。

13
Philip Rieck

私は規則を使用するのが好きです（一般的には良い考えです）が、UIの場合は、コントロールのタイプを前面に置き、その後に説明的な名前（LabelSummary、TextSummary、CheckboxIsValidなど）を付けるのが好きです。

マイナーに聞こえますが、タイプを最初に配置する主な理由は、すべてのラベル、チェックボックスなど、Intellisenseリストに一緒に表示されるためです。

6
Jeff Donnici

Winformsの観点からも、私は半ハンガリー人が嫌いです。

私の意見では最大の欠点であり、UIコードをたくさん書いたのは、ハンガリー語ではバグを見つけにくくなることです。テキストボックスのcheckedプロパティを変更しようとすると、コンパイラは通常それを取得しますが、次のようなものは取得しません。

lblSomeThing.Visible = someControlsVisible;
txtWhatThing.Visible = someControlsVisible;
pbSomeThing.Visible = someControlsVisible;

デバッグがはるかに簡単だと思います。

someThingLabel.Visible = someControlsVisible;
whatThingTextBox.Visible = someControlsVisible;
someThingPictureBox.Visible = someControlsVisible;

また、btnAddCommentsをbtnCloseWindowでグループ化するよりも、addCommentsButtonをaddCommentsTextBoxでグループ化する方がはるかに優れていると思います。最後の2つを一緒に使用するのはいつですか。

私が望むコントロールを見つける限り、私はフィリップ・リークに同意します。特定の論理概念（タイトルやコメントの追加など）に関連するすべてのコントロールを扱いたいことがよくあります。このコントロール上にあるテキストボックスの一部またはすべてを見つけたいとは思わないでしょう。

WPFには関係ないかもしれませんが、ハンガリー語は常に避けるべきだと思います。

4
Justin Doyle

それは主に個人的な好みであり、最も重要なのは一貫性を保つことであるという他の回答に同意します。

データバインディングの普及を考えると、名前付けの必要性について...考慮したいことの1つは、UIが自動テストの対象になるかどうかです。 [〜＃〜] qtp [〜＃〜] のようなものは、アプリケーション内の視覚要素を名前で検索するため、テストスクリプトを作成する自動化エンジニアは、タブやボタンなどの場合に非常に役立ちます（インタラクティブコントロール）はすべて適切な名前が付けられています。

3
Lyall

WPFでは、コントロールに名前を付ける必要はほとんどありません（または必要さえありません）。したがって、WPFのベストプラクティスを使用している場合は、何を使用してもかまいませんwouldコントロールに名前を付けますif名前を付ける理由があります。

実際にコントロールに名前を付けたい場合（たとえば、ElementName =またはTargetName =参照の場合）、名前の目的に基づいて説明する名前を選択することをお勧めします。たとえば、次のようになります。

<Border x:Name="hilightArea" ...>
   ...

<DataTrigger>
   ...
   <Setter TargetName="hilightArea" ...
1
Ray Burns

__のように、ユーザーインターフェイス名の前に2つのアンダースコアを付けると、デバッグ時に他のプロパティの前に並べ替えられます。 IntelliSenseを使用してコントロールを見つける必要がある場合は、__と入力するだけで、コントロールのリストが表示されます。これは、int _id;のように、モジュールレベルの変数の前に単一のアンダースコアを付けるという命名規則を継続します。

1
AMissico

Visual Basic 6コントロールの命名規則については、Microsoftの公式Webサイトを使用して、推奨されるC＃の命名規則と組み合わせることができます。これは非常に具体的で、C＃の開発者によってコントロール名にも広く使用されており、WPFまたはWindowsフォームのコンテキストでも使用できます。

Visual Basic 6コントロールの命名規則： オブジェクトの命名規則

C＃が推奨する一般的な命名規則： 一般的な命名規則

1
Mathias Lykkegaard Lorenzen