如何命名 GUI 元素？答案

【问题标题】：How to name GUI elements?如何命名 GUI 元素？
【发布时间】：2011-01-11 11:04:12
【问题描述】：

在编程中经常让我头疼的一件事是，当我在必须处理大量元素的域中没有任何命名约定时。在使用 UI 设计器（例如 Windows 窗体设计器）时，我显然会遇到这种情况。

每次我开始一个新项目时，我都试图重新发明一个“看似强大”的命名约定，但它总是在某些时候失败。对我来说，与命名 GUI 元素的经典代码定义相比，有两个主要问题：

您必须放置大量可以在同一范围内访问的变量（GUI 元素），因此您需要严格的命名约定才能快速找到正确的元素。
您经常需要访问特定类型的 GUI 控件（例如：TextBox、Label 等），因此 GUI 元素的最佳解决方案是根据它们的类型（匈牙利风格符号）命名它们，这可以是有时令人困惑，无法帮助快速找到正确的元素。

如果有人有一个文档描述了他为自己的项目发明的一个好的约定或一个强大的约定，我真的很想知道它！

注意：我没有将这个问题归类到 .NET 或 Windows Forms 标签下，它似乎适用于很多框架。如果没有，请告诉我。

编辑：

事实上，我最常用的约定是使用反向匈牙利符号（意味着类型在前），然后是基于 UI 元素层次结构的路径。例如，要轻松访问属于我的程序的“设置”选项卡的文本框，我会这样称呼它：

this.tb_settingTab_xxx

我使用这个约定的问题是它并不完美，当你有一个 UI 元素属于另一个也属于另一个也属于另一个的 UI 元素时，有时会失败......

我真正在寻找的是牢不可破且方便的命名约定。我很惊讶微软从未就此给出任何指导方针。还是我错了？（即 Mark Rushakoff 评论）。

【问题讨论】：

如果您在一个表单上有太多控件，这是否暗示您将表单重构为单个表单上的多个UserControls 可能是一个不错的选择？您要问的问题与“我在跟踪 1500 行方法中的所有变量时遇到问题”不远。
这显然是最好的解决方案。我经常说，因为我只在我存储和显示的数据使用相同模式的情况下考虑这个解决方案，在这种情况下我会做一个用户控制并重用它。这仍然是对精心设计的 UI 应用程序的最佳建议之一，但目前它不适用于我的某些项目。

标签： user-interface naming-conventions

【解决方案1】：

this post 中描述了各种命名约定。关键是在整个项目中保持一致。我处理了很多控件，但发现根据它们的本质来标记它们很简单。文本框 = tbMyControl，标签 = lblMyControl。如果“MyControl”位与相似方面相关（例如 tbUsername、lblUsername），则它们可能相同。但是，我正在访问的内容并没有混淆。如果您发现自己感到困惑，那么也许您尝试了太多不同的符号？保持简单和合乎逻辑。

【讨论】：

这就是我们所说的“反转匈牙利符号”。这就是我在第二个问题中所描述的。这是访问特定类型的 UI 控件的最快方式。但一个问题仍然存在。许多 UI 元素可能属于另一个 UI 元素。例如，一个 TextBox 可以属于 TabControlItem。我的意思是，在键入控件类型后，您仍然可以浏览到可以属于 5 个不同选项卡的 TextBox。我经常使用这种匈牙利符号，后跟 UI 元素层次结构路径（例如：tb_settingtab_portnumber），但我从未找到完美且牢不可破的约定。
当然，我对您的项目一无所知，但是拥有如此多的控件以致于违反约定可不是一件好事 :)。以您的 TabControl 为例。我假设您有两个与端口号相关的文本框，但在不同的选项卡菜单中？我个人有一个tbSetPortNumber 和tbCurrentPortNumber（前者在设置选项卡下，后者在主屏幕选项卡下）。类似于您的层次结构方法。如果这变得不堪重负，我认为需要进行一些重构，或者对 GUI 进行改造。
@keyboardP 很遗憾你的链接失效了

【解决方案2】：

注意：我在代码中使用了以下代码，这些代码涵盖了——有时是混合的——“原始”Win32、ATL/WTL 和 MFC，所以不要从字面上理解，而只是原理。（另外，请原谅m_）

我对标准控件类型使用两个字母的快捷方式，后跟类似于控件功能的名称（在大多数情况下，相同/接近标签）。相关控件的名称当然需要匹配 - 例如

CStatic m_stBasePath;
CEdit   m_edBasePath;
CButton m_cbBrowseBasePath;

它并不适用于所有场景，但通常我会说一个对话框，如果它不再足够好，可能已经为用户提供了许多控件。

我写了三段，标题可以是“细节和辩护”——后来删除了它们，因为有一个非常明确的本质：

一致性。

我主要使用对话资源本身进行定位，并且资源 ID 和关联成员之间具有严格的等效性。所以“基本路径”相关的控件不是按字母顺序排列在一起的，但我很少认为这是一个问题。

标准控件类型已经包含有关控件功能的非常明显的信息 - 启用/禁用一组功能或布尔选项的复选框，用于输入/选择值的编辑或下拉菜单，用于打开的按钮子对话框、标签的静态控件等。

如果您将其转移到具有更多控件的平台或使用大量自定义控件时，我不确定这种样式如何转移，因为我的 WinForms 项目相对较小。

【讨论】：

与 TenaciousImpy 答案相同的评论。谢谢。