Question

在编程中不断引起我头痛的一件事是当我在域中没有任何命名约定时我必须处理很多元素。很明显，在使用Windows设计器等UI设计器时，我发生了什么。

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

你必须放置很多变量（GUI元素），这些变量都可以在同一范围内访问，所以你需要有一个强大的命名约定来快速找到正确的元素。
您经常需要访问特定类型的GUI控件（例如：TextBox，Label，...），因此GUI元素的最佳解决方案是在它们的类型（匈牙利风格符号）之后命名它们，这可以是有时令人困惑，无法帮助快速找到合适的元素。

如果某人有一份描述他为自己的项目发明的良好惯例或强烈约定的文件，我真的很想知道它！

注意：我没有在.NET或Windows Forms标签下对此问题进行分类，它似乎适用于很多框架。如果没有，请告诉我。

编辑：

事实上，我最常用的约定是使用反向匈牙利表示法（意思是类型首先出现），然后是基于UI元素层次结构的路径。例如，要轻松访问属于我的程序“设置”选项卡的TextBox，我会这样称呼它：

this.tb_settingTab_xxx

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

我真正在寻找的是牢不可破且方便的命名惯例。我非常惊讶微软从未就此提出过任何指导原则。或者我错了？（即Mark Rushakoff评论）。

Answer 1

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

Answer 2

注意：我在代码中使用以下内容 - 有时混合 - “原始”Win32，ATL / WTL和MFC，所以不要从字面上理解，只有原则。（另外，请原谅m_）

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

CStatic m_stBasePath;
CEdit   m_edBasePath;
CButton m_cbBrowseBasePath;

对于所有场景来说，它并不完美，但通常我会说一个不太好的对话框可能已经为用户提供了许多控件。

我写过三段可以标题为“细节和防御”的内容 - 后来删除了它们，因为它有一个非常清晰的本质：

<强>一致性即可。

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

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

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

如何命名GUI元素？

2 个答案: