WPF UI元素命名规范

Question

尽管匈牙利命名法现在被认为是不好的做法，但在编码用户界面元素时，仍然很常见将类型编码到名称中，可以使用前缀（lblTitle，txtFirstName，...）或后缀（TitleLabel，FirstNameTextBox，...）。在我们公司，我们也这样做，因为这使得同事编写的代码（或者你自己很久以前编写的代码）更容易阅读（根据我的经验）。通常提出反对这样做的论点——如果类型发生变化，你必须更改变量的名称——并不是很有力，因为更改 UI 元素的类型通常需要重写引用它的所有代码部分。所以，当开始进行 WPF 开发时，我考虑继续保持这种做法（嗯...我们应该为 TextBlocks 或 TextBoxes 使用 txt 前缀吗？）。我是否忽略了任何重要的缺点？这是你说“不要这样做，因为...”的机会。编辑：我知道使用数据绑定可以减少命名 UI 元素的需求。尽管如此，有时仍然是必要的，例如开发自定义控件...

- Heinzi

---

实际上从来不需要给TextBlock命名，所以“txt”问题可能是无关紧要的。事实上，只有在需要从代码或其他地方访问它时才需要命名任何内容。由于大多数WPF UI都是通过数据绑定和在XAML中声明的，这极大地减少了需要命名每个控件的需求。 - Joey

如果其他 UI 元素使用 ElementName 绑定到它们，您还需要为它们命名。 - Wonko the Sane

Answer 1

就我个人而言，我认为WPF在这方面改变了规则。通常情况下，你可以少些或者完全不需要编写代码，因此使用前缀来区分名称反而使事情更加混乱而不是更加简单易懂。

在Windows Forms中，每个控件都在代码中通过名称引用。对于大型UI，半匈牙利命名法很有用——它更容易区分你正在处理的内容。

然而，在WPF中，几乎没有控件需要名称。当您确实需要通过代码访问控件时，最好使用附加属性或行为来执行此操作，这样您就永远不会处理超过一个控件。如果您在UserControl或Window代码后台工作，我建议使用"Title"和"Name"代替"txtTitle"，特别是现在您可能只涉及少量受限控件，而不是所有控件。

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

- Reed Copsey

---

“PART_Name” 前缀约定仍在使用吗？ - Piotr Golacki

如果您检查Visual Studio自动生成的样式和模板，您会发现它们没有前缀和后缀，并且只使用小写字母命名。例如，在Expander默认样式中： <Ellipse x:Name="circle"/> <Image x:Name="arrow"/> - eulerleibniz

Answer 2

根据我的经验，在WPF中，当你更改控件的类型时，通常不需要重新编写任何代码，除非你做错了什么。实际上，大多数情况下，你不会在代码中引用控件。是的，最终你会这么做，但是WPF中对UI元素的引用大多是由同一XAML中的其他元素进行的。

个人而言，我认为“lblTitle，lblCompany，txtFirstName”比“Title”更难读。我没有.intWidth和.intHeight（再见lpzstrName！）。为什么要有.lblFirstName？我可以更好地理解TitleField或TitleInput等名称，因为它们描述的是“what”，而不是“how”。

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

- Philip Rieck

Answer 3

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

在我看来，最大的缺点是，它使得错误更难以发现。尽管编译器通常会检测到如果你试图更改文本框的checked属性，但它不会检测到像这样的问题：

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

我发现调试起来容易得多：

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

我认为将添加评论按钮与添加评论文本框分组要比将btnAddComments与btnCloseWindow分组要好得多。你什么时候会同时使用后两个？

就我想要找到的控件而言，我同意Philip Rieck的观点。我经常想处理与特定逻辑概念（如标题或添加评论）相关的所有控件。我几乎从不想找到只是发生在这个控件上的任何或所有文本框。

在WPF中可能不相关，但我认为应该始终避免使用匈牙利命名法。

- Justin Doyle

Answer 4

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

听起来很小，但将类型放在前面的主要原因是它们会在Intellisense列表中一起出现--所有标签一起，复选框等等。

- Jeff Donnici

---

我同意你所说的一切，出于同样的原因，我也做同样的事情。 - Gabriel Magana

如果你发现自己经常使用Intellisense将控件名称输入到代码中，那很可能意味着你正在像“旧的WinForms”一样使用WPF，并没有充分利用WPF的高级功能（数据绑定、模板等）。 - Ray Burns

我不否认WPF与“陈旧的Winforms”有着不同的使用模式，但只需要查找一次控件名称，我就能欣赏到一种使它们易于查找的惯例。 - Jeff Donnici

有时候这也可能很麻烦——我想找到标题，所以我尝试 TextTi... 哎呀。它是组合框吗？ComboTitl... 呃，不是。噢，我们只允许两个——也许用单选按钮？RadioTitle！啊哈！ - Philip Rieck

Answer 5

同意其他答案的观点，这主要取决于个人偏好，最重要的是保持一致性。

关于是否需要命名，考虑到数据绑定的普及...你可能需要考虑的一件事是，如果你的UI需要自动化测试。像QTP这样的工具通过名称查找应用程序中的可视元素，因此编写测试脚本的自动化工程师会非常欣赏诸如选项卡、按钮等（任何交互控件）都有良好的命名。

- Lyall

Answer 6

在WPF中，你实际上几乎不需要（甚至不想）给你的控件命名。因此，如果你使用WPF最佳实践，那么无论你有没有理由给它们命名，你都不需要关心你会给你的控件起什么名字。

在那些罕见的情况下，当你确实想要给一个控件命名时（例如为了ElementName=或TargetName=引用），我更喜欢根据名称的目的选择一个描述性的名称，例如：

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

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

- Ray Burns

Answer 7

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

- AMissico

Answer 8

您可以使用官方的微软网站来查看Visual Basic 6控件命名规范，并结合推荐的C#命名规范。这些规范非常具体，被C#开发人员广泛使用于控件名称中，并且仍然可以在WPF或Windows Forms上下文中使用。

Visual Basic 6控件命名规范：Object Naming Conventions

C#推荐的通用命名规范：General Naming Conventions

- Mathias Lykkegaard Lorenzen