C # GUI 命名约定的最佳实践？

GUI，无论是用 WinForms 还是 XAML 编写的，似乎在我看到的项目之间有着最广泛的不同命名约定。对于一个人名的简单 TextBox，我见过各种命名约定:

TextBox tbName      // Hungarian notation
TextBox txtName     // Alternative Hungarian
TextBox NameTextBox // Not even camelCase
TextBox nameTextBox // Field after field with TextBox on the end
TextBox TextBoxName // Suggested in an answer...
TextBox textBoxName // Suggested in an answer...
TextBox uxName      // Suggested in an answer...
TextBox name        // Deceptive since you need name.Text to get the real value
TextBox textBox1    // Default name, as bad as you can get

我遵守 StyleCop 的规则。Cs 文件，并看到其他人也这样做，但图形用户界面往往打破这些规则或变化很大。我还没有看到任何微软的指导方针专门指向 GUI 元素，而不仅仅是普通变量，甚至是应用于控制台应用之外的例子。

在 GUI 中命名元素的最佳实践是什么？

47743 次浏览
小开

命名惯例最重要的一点就是选择一些有意义的东西，从各方获得一致意见，并坚持下去，就像你的生活依赖于它一样。

至于使用哪种公约，我会投票支持这个公约:

TextBox name

它是简短的，具有作为标识符的语义价值。至于标识符的 类型，我将依赖 VisualStudio 来告诉您，因为它往往擅长这类事情。

小开

我将所有 UI 元素命名为 TypeDescriptor。

小开

我使用匈牙利命名法，这使得在大页面中很容易找到控件。

小开
最佳答案

我用老式的匈牙利语... txt 表示 TextBox，btn 表示 Button，后面跟着一个通用的单词，然后是一个更具体的单词。例如:

btnUserEmail

有很多人说过类似 “我的天哪，这么老，VB6呼叫!”的东西，但是在 UI Rich winform 应用程序中，我可以更快地找到和修改东西，因为通常你知道的第一件事就是一个控件的类型，然后它的类别，然后得到具体的。而新型的变数命名原则们却在努力记住他们给那个文本框起的名字。

控件的原始规范在这里(归档)。

小开

我最近一直在与一个正在从 MFC (6.0...)转移的团队合作。在那里他们会有

CString Name;
CEdit ctlName;

迁移的最简单方法是使用

TextBox ctlName

这只是一个提醒，即变量是控件，而不是控件的值。

我认为将类型作为名称的一部分只是 OLD。

编辑 另一个好处是在导航时将所有控件组合在一起。如果使用实际类型，ComboBox 控件将远离 TextBox 控件。

小开

对于我不打算在代码中使用的元素，我只是让设计师为我处理它; 如果它们确实成为我的代码中使用的东西，它们就会变成有意义的东西，那就是 描述类型(nameTextBox)。如果提供了足够的信息，设计器就这样创建它们(查看菜单项——“ Exit”变成了 exitMenuItem)。

小开

我用:

TextBox nameTextBox;

就像我会用:

MailAddress homeAddress;

这样做的原因是，在这些情况下，“ TextBox”和“ Address”描述的是对象表示的内容，而不是对象的存储或使用方式。但在另一种情况下，比如存储一个人的全名，我会使用:

string fullName;

不是:

string fullNameString;

因为“字符串”不是描述对象表示什么，而只是描述它是如何存储的。

小开

和英国其他地方的习俗一样。NET: 只使用驼峰大小写描述性名称，如果需要区分同一逻辑“事物”的不同类，可以选择后跟一个后缀。例如:

string name; // a name
TextBox nameText; // the control used to edit the name
Label nameLabel; // the control used to label the edit control
List<string> nameList; // a list of names

诸如此类。后缀是什么并不重要，只要它们是一致的和描述性的。

小开

我自己的实践是: Type _ contextDescriptionType。 例如:

TextBox _searchValueTextBox

无论如何，变数命名原则要么太个人化，要么是由一般规则强加的。无论如何，它应该被记录在某个地方，这样所有的项目开发人员都可以很容易地访问。

小开

这不是我的发明，但我喜欢它:

TextBox uxName = new TextBox();
Label uxNameLabel = new Label();
Button uxAccept = new Button();

我更喜欢这个匈牙利命名法，因为我所有的 UI 控件都显示在一个智能块中。“用户体验”的用户体验。如果您将一个控件从文本框更改为组合框或其他东西，这也很好，因为名称不会更改。

小开

我倾向于使用 c _ typeName (请注意类型和名称是不同的) ，例如 c _ tbUserEmail 用于 TextBox，用户应该在其中键入他/她的电子邮件。我发现它很有用，因为当有很多控件时，很难在数英里长的智能感知列表中找到它们，所以通过添加 c _ 前缀，我可以很容易地看到该表单中的所有控件。

小开

我希望有人能够成为这方面的权威，直接告诉它，并开始执行它... ... 对我来说最糟糕的事情是，当人们在同一个应用程序或更糟糕的是同一个类混淆。

我见过一些非常可怕的东西，txtName、 NameTextBox、 name 和 textBox1都用在同一个表单上... ... 恶心。

在我工作的地方，我们有一个标准文件，告诉我们如何做，在哪里做，我认为只有20% 的人，甚至关心尝试和遵守。

我通常会改变一些事情，如果 Fxpolice 对我大喊大叫。

Http://en.wikipedia.org/wiki/naming_conventions_%28programming%29

资本化风格

请注意: Microsoft. NET 推荐 UpperCamelCase (又名“ Pascal Style”)用于大多数标识符(参数推荐使用 lowerCamelCase)。

小开

这种以匈牙利人和 VB6命名的疯狂行为必须停止。

如果微软真的想让你根据控件的类型来命名控件，那么为什么 Visual Studio 在你将控件添加到 web/win 表单时不自动添加“ txt”或“ btn”呢？

小开

我用的是匈牙利符号，只有一点点不同。

我现在从事的项目有一个相当丰富的 UI。因此，使用 Intellisense 找到一个名为 btnGetUsers 的按钮非常容易。

当应用程序能够从不同的位置获得用户时，事情就变得复杂了。这是不同的控制。因此，我开始用控件的位置来命名它们，并且仍然使用匈牙利命名法。

例如: tabSchedAddSchedTxbAddress 意味着 txbAddress 是一个文本框，可以在其中插入一个地址，该地址位于“计划”选项卡控件的“添加计划”选项卡上。 通过这种方式，我可以很容易地找到控件，而且，当我简单地输入“ btn”时，我不会立即得到来自用户界面各处的大量按钮。

当然，这只是为了帮助我自己。我不知道有这么好的做法。然而，它帮助了很多。

摩苏

小开

你有来自微软的 名称指南。我没有跟随所有的东西，但它是一个很好的起点

小开

我相信变数命名原则的存在是为了减轻开发人员的编码工作，并有助于提高可管理性。据我所知，任何有助于方便访问的名称应遵循。

我看到许多不同方法的评论，但我发现我的项目中最好的是前缀控制的前三个名称。遵循这种方法背后有很多原因。

  1. 智慧感觉会把所有相同类型的人聚集在一起。
  2. 窗体属性窗口还将显示排序后的所有相同控件
  3. 在复杂的表单上，您可以很容易地识别您正在处理的标签或文本框(例如 lblAccount 和 txtAccount)
  4. 新用户可以很容易地处理编码。
  5. 假设我在相同的表单上有 Account Lst、 Accountlbl、 account ttxt、 Accountgrd、 AccountChk 控件。

在编写代码时，开发人员总是知道他正在访问文本框或标签。由于他不清楚其他开发商使用了什么名称。所以只要写上“ lbl”，tellisense 就会带来所有的标签列表供选择，如果您使用了 # 5中使用的方法，那么 tellisense 就会带来使用 acc 的所有控件。我很少看到做一些循环与控件名称开始“帐户”左右。这意味着它不会在任何罕见的事件帮助。

我打赌是做一些有助于其他开发人员轻松理解代码的事情。因为当你在你的航空公司长大，你不会总是做编码，会有其他人来取代你的位置。

选择权在你，你想怎么做！

小开

如果应用程序的设计有一个很好的关注点分离，我想就没有必要把按钮命名为 LoginButton、 LoginBtn 或 btnLogin。如果对象的所有者是一个 UI 元素，那么我们就称它为 Login，如果所有者不是一个 UI 元素，那么对象就位于错误的位置。


提交答案