WPF UI 元素命名约定答案

【问题标题】：WPF UI element naming conventionsWPF UI 元素命名约定
【发布时间】：2009-11-16 17:02:45
【问题描述】：

虽然Hungarian notation 现在被认为是不好的做法，但在用户界面元素的名称中编码类型仍然很常见，或者使用前缀（lblTitle、txtFirstName , ...) 或后缀 (TitleLabel, FirstNameTextBox, ...)。

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

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

编辑：我知道通过数据绑定来命名 UI 元素的需求减少了。然而，有时它是必要的，例如在开发自定义控件时...

【问题讨论】：

实际上不需要命名 TextBlock，因此 txt 问题可能是一个有争议的问题。事实上，如果你需要从代码中访问它，你只需要命名任何东西。由于大多数 WPF UI 由数据绑定驱动并在 XAML 中声明，这大大减少了为每个控件命名的需要。
如果其他 UIElement 使用 ElementName 绑定绑定到它们，您还需要命名它们。

标签： wpf coding-style

【解决方案1】：

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

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

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

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

【讨论】：

是否仍使用PART_Name 前缀约定？

【解决方案2】：

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

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

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

【讨论】：

【解决方案3】：

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

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

【讨论】：

同意你所说的，我出于同样的原因做同样的事情。
如果您发现自己经常使用 Intellisense 在代码中键入控件名称，这可能意味着您使用 WPF 就好像它是“糟糕的旧 WinForms”，并且没有充分利用 WPF 的高级功能功能（数据绑定、模板等）。
我不反对 WPF 与“糟糕的旧 Winforms”有不同的使用模型，但我只需要查找一次控件名称即可了解使它们易于查找的约定。
这有时也很痛苦 - 我想找到标题，所以我尝试了 TextTi...哎呀。是组合吗？ ComboTitl...呃，不。哦，我们只允许两个 - 也许是一个单选按钮？电台标题！啊哈！

【解决方案4】：

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

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

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

我发现它更容易调试：

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

我还认为将 addCommentsButton 与 addCommentsTextBox 组合比将 btnAddComments 与 btnCloseWindow 组合要好得多。你什么时候会同时使用最后两个？

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

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

【讨论】：

【解决方案5】：

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

考虑到数据绑定的普遍性，关于命名的必要性……您可能需要考虑的一件事是您的 UI 是否曾经接受过自动化测试。像QTP 这样的东西可以通过名称在应用程序中找到可视元素，因此，如果选项卡、按钮等（任何交互式控件）都被很好地命名，那么编写测试脚本的自动化工程师会非常感激。

【讨论】：

【解决方案6】：

在 WPF 中，您几乎不需要（甚至不想）为控件命名。因此，如果您使用 WPF 最佳实践，那么为控件命名并不重要如果您有理由为它们命名。

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

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

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

【讨论】：

【解决方案7】：

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

【讨论】：

【解决方案8】：

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

Visual Basic 6 控件命名约定：Object Naming Conventions

C# 推荐的一般命名约定：General Naming Conventions

【讨论】：