如何命名 GUI 元素？
在编程中经常让我头痛的一件事是，当我在必须处理很多元素的域中没有任何命名约定时。这显然是我在使用 UI 设计器（例如 Windows 窗体设计器）时发生的情况。
每次我开始一个新项目时，我都试图重新发明一个“看似强大”的命名约定，但它总是在某些时候失败。对我来说，与命名 GUI 元素的经典代码定义相比，有两个主要问题：
- 您必须放置大量变量（GUI 元素），这些变量都可以在同一范围内访问，因此您需要有一个强大的命名约定快速找到正确的元素。
- 您经常需要访问特定类型的 GUI 控件（例如：TextBox、Label...），因此 GUI 元素的最佳解决方案是根据其类型（匈牙利风格表示法）来命名它们，这有时可能会造成混淆无助于快速找到正确的元素。
如果有人有一个文档描述了他为自己的项目发明的良好约定或强大约定，我真的很想知道！
注意：我没有将这个问题分类在 .NET 或 Windows Forms 标签下，它似乎适用于很多框架。如果没有，请告诉我。
编辑：
事实上，我最常用的约定是使用反向匈牙利表示法（意味着类型首先），然后是基于 UI 元素层次结构的路径。例如，为了轻松访问属于我的程序的“设置”选项卡的文本框，我会这样称呼它：
this.tb_settingTab_xxx
我使用此约定的问题是它并不完美，当您有一个属于的 UI 元素时，它有时会失败another 也属于 another 也属于...
我真正寻找的是牢不可破且方便的命名约定。令我感到非常惊讶的是，微软从未就此提供任何指导。还是我走错了？ （即马克鲁沙科夫评论）。
One thing that constantly causing me headache in programming is when I don't have any naming-convention in a domain where I have to deal with a lot elements. It is clearly what is happening to me when using UI designers such as Windows Forms designer.
Everytime I start a new project I am trying to reinvent a "seem-strong" naming convention but it always fail at some points. For me there is 2 main problems compared to classic code definition for naming GUI elements:
- You have to place a lot of variables (GUI elements) which can all be accessed in the same scope, so you need to have to a strong naming convention to find quickly the right element.
- You often need to access to a specific type of GUI control (ex: TextBox, Label, ...), so the best solution for GUI elements is to name them after their types (Hungarian style notation), which can be sometimes confusing and not helping in finding the right element quickly.
If someone has a documentation describing a good convention or a strong convention he invented for its own project, I would really like to know it!
NB: I did not classified this question under .NET or Windows Forms tags has it seems applicable to a lot of frameworks. If not, let me know.
EDIT:
In fact the convention I most use is using a reversed hungarian notation (meaning the type comes first) followed by a path based on the UI elements hierarchy. For example, to easily access to a TextBox which belongs to the "Settings" tab of my program I would call it this way:
this.tb_settingTab_xxx
My problem using this convention is that it is not perfect and sometimes fails when you have a UI element that belongs to another which also belongs to another which also belongs to ...
I am really searching for is the unbreakable and handy naming-convention. I am quitely surprised that Microsoft never gaved any guidelines concerning this. Or am I going wrong? (ie. Mark Rushakoff comment).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这篇文章。关键是在整个项目中保持一致。我处理过很多控件，但发现根据它们的含义来标记它们很简单。文本框 = tbMyControl，标签 = lblMyControl。如果“MyControl”位涉及相似的方面（例如tbUsername、lblUsername），则它们可能是相同的。但是，我正在访问的内容并不混乱。如果您发现自己感到困惑，那么也许您尝试了太多不同的符号？保持简单和逻辑。There are various naming conventions described in
this post. The key is to remain consistent throughout the project. I deal with a lot of controls, but find it straightforward to label them based on what they are. Textbox = tbMyControl, Label = lblMyControl. The 'MyControl' bit might be the same if they relate to similar aspects (e.g. tbUsername, lblUsername). However, there's no confusion on what I'm accessing. If you find you're getting confused, then maybe you're trying too many different notations? Keep it simple and logical.注意：我在涵盖（有时混合）“原始”Win32、ATL/WTL 和 MFC 的代码中使用了以下内容，因此不要从字面上理解它，仅了解其原理。 （另外，请原谅
m_）我对标准控件类型使用两个字母的快捷方式，后跟与控件功能类似的名称（在大多数情况下，相同） / 靠近标签）。当然，相关控件的名称需要匹配 - 例如，
它并不适合所有场景，但通常我会说，一个不再足够好的对话框可能已经为用户提供了许多控件。
我写了三段可以称为“细节和辩护”的段落 - 随后将其删除，因为有一个非常明确的本质：
一致性。
我主要使用对话框资源本身进行定位，并且资源 ID 和关联成员之间具有严格的等效性。因此，“基本路径”相关控件并不按字母顺序排列在一起，但我很少认为这是一个问题。
标准控件类型已经包含有关控件功能的非常明显的信息 - 用于启用/禁用一组功能或布尔选项的复选框、用于输入/选择值的编辑或下拉菜单、用于打开子对话框的按钮、标签的静态控件等。
如果您将其转移到具有更多控件的平台或使用大量自定义控件时，我不确定这种样式如何转移，因为我的 WinForms 项目相对较小。
Note: I use the following in code that covers - and sometimes mixes - "raw" Win32, ATL/WTL and MFC, so don't take it literally, only the principle. (Also, be forgiving on the
m_)I use a two-letter-shortcut for standard control types, followed by the name which resembles the functionality of the control (in most cases, Identical / close to the label). The name of related controls needs to match of course - e.g.
It's not perfect for all scenarios, but generally I'd say a dialog where this isn't good enough anymore might have to many controls for the user already.
I've written three paragraphs that could be titled "details and defense" - and subsequently deleted them, since there's a very clear essence:
Consistency.
I mostly use the dialog resource itself for orientation, and have strict equivalence between resource ID's and associated members. So the "Base path" - related controls aren#t together in an alphabetic order, but I rarely see this as a problem.
The standard control type already contains very obvious information about functionaltiy of a control - a checkbox to enable / disable a group of features or for a boolean option, an edit or drop down to enter/select a value, a button to open a sub dialog, a static control for the label, etc.
I'm not sure how this style transfers if you transfer it to a platform with much more controls or when you use a lot of custom controls, as my WinForms projects have been comparedly small.