WPF UI 元素命名约定

WPF UI element naming conventions

提问by Heinzi

Although Hungarian notationis considered bad practice nowadays, it is still quite common to encode the type in the name of user interface elements, either by using a prefix (lblTitle, txtFirstName, ...) or a suffix (TitleLabel, FirstNameTextBox, ...).

尽管现在匈牙利表示法被认为是不好的做法，但通过使用前缀 ( , , ...) 或后缀 ( , , ...)以用户界面元素的名称对类型进行编码仍然很常见。lblTitletxtFirstNameTitleLabelFirstNameTextBox

In my company, we also do this, since it makes code written by co-workers (or by yourself a long time ago) easier to read (in my experience). The argument usually raised against doing this -- you have to change the name of the variable if the type changes -- is not very strong, since changing the type of a UI element usually requires rewriting all parts of the code were it is referenced anyway.

在我的公司，我们也这样做，因为它使同事（或很久以前自己）编写的代码更易于阅读（以我的经验）。通常反对这样做的论点——如果类型改变，你必须改变变量的名称——不是很强烈，因为改变 UI 元素的类型通常需要重写代码的所有部分，不管它是否被引用.

So, I'm thinking about keeping this practice when starting with WPF development (hmmm... should we use the txtprefix for TextBlocks or TextBoxes?). Is there any big disadvantage that I have missed? This is your chance to say "Don't do this, because ...".

所以，我正在考虑在开始 WPF 开发时保持这种做法（嗯……我们应该使用txtTextBlocks 还是 TextBoxes的前缀？）。我错过了什么大缺点吗？这是您说“不要这样做，因为……”的机会。

EDIT: I know that with databinding the need to name UI elements decreases. Nevertheless, it's necessary sometimes, e.g. when developing custom controls...

编辑：我知道使用数据绑定来命名 UI 元素的需求减少了。尽管如此，有时还是有必要的，例如在开发自定义控件时...

回答by Reed Copsey

Personally, I find that WPF changes the rules when it comes to this. Often, you can get away with little or no code behind, so having the prefixes to distinguish names makes things more confusing instead of less confusing.

就我个人而言，我发现 WPF 在这方面改变了规则。通常，您可以使用很少的代码或没有代码，因此使用前缀来区分名称会使事情变得更加混乱而不是不那么混乱。

In Windows Forms, every control was referenced by name in code. With a large UI, the semi-hungarian notation was useful - it was easier to distinguish what you were working with.

在 Windows 窗体中，每个控件都通过代码中的名称进行引用。对于大型 UI，半匈牙利符号很有用 - 更容易区分您正在使用的内容。

In WPF, though, it's a rare control that needs a name. When you do have to access a control via code, it's often best to use attached properties or behaviors to do so, in which case you're never dealing with more than a single control. If you're working in the UserControl or Window code-behind, I'd just use "Title" and "Name" instead of "txtTitle", especially since now you'll probably only be dealing with a few, limited controls, instead of all of them.

但是，在 WPF 中，它是一种需要名称的罕见控件。当您确实必须通过代码访问控件时，通常最好使用附加属性或行为来执行此操作，在这种情况下，您永远不会处理多个控件。如果您在 UserControl 或 Window 代码隐藏中工作，我将只使用“Title”和“Name”而不是“txtTitle”，特别是因为现在您可能只会处理一些有限的控件，而不是所有这些。

Even custom controls shouldn't need names, in most cases. You'll want templated names following convention (ie: PART_Name), but not actual x:Name elements for your UIs...

在大多数情况下，甚至自定义控件也不需要名称。您需要遵循约定的模板化名称（即：PART_Name），但不是您的 UI 的实际 x:Name 元素...

回答by Philip Rieck

In my experience - In WPF when you change the type of a control, you normally do not have to rewrite any code unless you did something wrong. In fact, most of the time you do not reference the controls in code. Yes, you end up doing it, but the majority of references to a UI element in WPF is by other elements in the same XAML.

根据我的经验 - 在 WPF 中，当您更改控件的类型时，除非您做错了什么，否则通常不必重写任何代码。事实上，大多数时候您不会在代码中引用控件。是的，您最终会这样做，但是对 WPF 中 UI 元素的大部分引用是由同一 XAML 中的其他元素引用的。

And personally, I find "lblTitle, lblCompany, txtFirstName" harder to read than "Title". I don't have .intWidth and .intHeight (goodbye lpzstrName!). Why have .lblFirstName? I can understand TitleField or TitleInput or whatever a lot more as it's descriptive of the what, not the how.

就个人而言，我发现“lblTitle、lblCompany、txtFirstName”比“Title”更难阅读。我没有 .intWidth 和 .intHeight （再见 lpzstrName！）。为什么有 .lblFirstName？我可以理解 TitleField 或 TitleInput 或其他更多内容，因为它描述的是什么，而不是如何。

For me, wishing to have that type of separation normally means my UI code is trying to do too much - of course it's dealing with a UI element, it's in the window code! If I'm not dealing with code around a UI element, why in the world would I be coding it here?

对我来说，希望有这种类型的分离通常意味着我的 UI 代码试图做太多事情 - 当然它正在处理一个 UI 元素，它在窗口代码中！如果我不处理围绕 UI 元素的代码，我为什么要在这里编写代码？

回答by Jeff Donnici

I like using a convention (just a good idea in general), but for UI stuff I like it to have the type of the control at the front, followed by the descriptive name -- LabelSummary, TextSummary, CheckboxIsValid, etc.

我喜欢使用约定（通常只是一个好主意），但对于 UI 内容，我喜欢将控件类型放在前面，然后是描述性名称——LabelSummary、TextSummary、CheckboxIsValid 等。

It sounds minor, but the main reason for putting the type first is that they'll appear together in the Intellisense list -- all the labels together, checkboxes, and so on.

这听起来微不足道，但将类型放在首位的主要原因是它们将一起出现在 Intellisense 列表中——所有标签、复选框等等。

回答by Justin Doyle

Even from a Winforms perspective I dislike semi-hungarian.

即使从 Winforms 的角度来看，我也不喜欢半匈牙利人。

The biggest disadvantage in my opinion, and I've written a LOT of ui code is that hungarian makes bugs harder to spot. The compiler will generally pick it up if you try to change the checked property on a textbox, but it won't pick up something like:

在我看来，最大的缺点是，我写了很多 ui 代码是匈牙利语使错误更难发现。如果您尝试更改文本框上的 checked 属性，编译器通常会选择它，但它不会选择以下内容：

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

I find it MUCH easier to debug:

我发现调试要容易得多：

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

I also think it's far better to group an addCommentsButton with an addCommentsTextBox than to group a btnAddComments with a btnCloseWindow. When are you ever going to use the last two together?

我还认为将 addCommentsButton 与 addCommentsTextBox 分组比将 btnAddComments 与 btnCloseWindow 分组要好得多。你什么时候打算一起使用最后两个？

As far as finding the control I want, I agree with Philip Rieck. I often want to deal with all the controls that relate to a particular logical concept (like title, or add comments). I pretty much never want to find just any or all text boxes that happens to be on this control.

至于找到我想要的控制，我同意 Philip Rieck。我经常想处理与特定逻辑概念（如标题或添加注释）相关的所有控件。我几乎从不想找到恰好在此控件上的任何或所有文本框。

It's possibly irrelevant in WPF, but I think hungarian should be avoided at all times.

这在 WPF 中可能无关紧要，但我认为应该始终避免使用匈牙利语。

回答by Lyall

Agree with the other answers that it's mainly personal preference, and most important is just to be consistent.

同意其他答案，这主要是个人喜好，最重要的是保持一致。

On the need for naming at all, given the prevalence of data binding... one thing you might want to consider is if your UI is ever subjected to automated testing. Something like QTPfinds the visual elements in an application by Name, and so an automation engineer writing test scripts will greatly appreciate when things like tabs, buttons etc. (any interactive control) are all well named.

考虑到数据绑定的普遍性，完全需要命名……您可能需要考虑的一件事是您的 UI 是否曾经进行过自动化测试。Something like QTPfinds the visual elements in an application by Name, and so an automation engineer writing test scripts will greatly appreciate when things like tabs, buttons etc. (any interactive control) are all well named.

回答by AMissico

I prefix any user-interface name with two underscores, as in __so it is sorted before other properties when debugging. When I need to use IntelliSense to find a control, I just type __ and a list of controls displays. This continues the naming convention of prefixing a single underscore to module level variables, as in int _id;.

我用两个下划线作为任何用户界面名称的前缀，__这样在调试时它会排在其他属性之前。当我需要使用 IntelliSense 查找控件时，我只需键入 __ 即可显示控件列表。这延续了在模块级变量前添加单个下划线的命名约定，如int _id;.

回答by Mathias Lykkegaard Lorenzen

You can use the official Microsoft website for Visual Basic 6 control naming conventions, and perhaps combine it with the recommended C# naming conventions. It's very specific, is widely used by developers in C# as well for control names, and can still be used in a WPF or Windows Forms context.

您可以使用 Microsoft 官方网站获取 Visual Basic 6 控件命名约定，也可以将其与推荐的 C# 命名约定结合使用。它非常具体，在 C# 中被开发人员广泛用于控件名称，并且仍然可以在 WPF 或 Windows 窗体上下文中使用。

Visual Basic 6 control naming conventions: Object Naming Conventions

Visual Basic 6 控件命名约定：对象命名约定

C# recommended naming conventions in general: General Naming Conventions

C# 推荐的一般命名约定：通用命名约定

回答by Ray Burns

In WPF you practically never need (or even want) to name your controls. So if you're using WPF best practices it won't matter what you wouldname your controls ifyou had a reason to name them.

在 WPF 中，您几乎不需要（甚至不想）命名您的控件。所以，如果你使用WPF最佳做法，它不会不管你怎么会命名您的控件，如果你有一个理由给它们命名。

On those rare occasions where you actually do want to give a control a name (for example for an ElementName= or TargetName= reference), I prefer to pick a name describing based on the purpose for the name, for example:

在极少数情况下，您确实想要为控件命名（例如，对于 ElementName= 或 TargetName= 引用），我更喜欢根据名称的用途选择一个名称，例如：

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

<DataTrigger>
   ...
   <Setter TargetName="hilightArea" ...