C# GUI 命名约定的最佳实践？ [关闭]

Posted 2023-02-22

【中文标题】C# GUI 命名约定的最佳实践？ [关闭]

【英文标题】：Best practices for C# GUI naming conventions? [closed]

【发布时间】：2010-11-17 19:23:12

【问题描述】：

无论是用 WinForms 还是 XAML 编写的 GUI，我所看到的项目之间的命名约定似乎都存在最大差异。对于一个简单的人名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

我的所有 .cs 文件通常都遵守 StyleCop 规则，并且看到其他人也这样做，但 GUI 往往会违反这些规则或变化很大。我没有看到任何 Microsoft 指南专门提到 GUI 元素而不仅仅是普通变量，甚至没有看到适用于控制台应用程序之外的示例。

在 GUI 中命名元素的最佳做法是什么？

【问题讨论】：

"textBox1" 只有在代码中实际引用它时才会“尽你所能”。

@Austin：在这种情况下，WinForms 你应该将 Generate Member 设置为 false，而 XAML 你根本不应该定义 x:Name。

对不起，没有好的分析器，我自己喜欢 textBoxName 和 lableName 但觉得很难辩护。

同意Guard，generate成员默认设置为false。事实上，我会在我没有明确使用的任何东西上手动将其设置为 false。

NOT 的参数在这里使用匈牙利符号：***.com/questions/111933/…

【参考方案1】：

我使用老式的匈牙利语... txt 代表文本框，btn 代表按钮，然后是一个通用词，然后是一个更具体的词。即：

btnUserEmail

已经有很多人说“天哪，太老了，VB6 调用！” 但是在 UI 丰富的 winforms 应用程序中，我可以更快地找到和修改内容，因为通常你首先要做的就是了解控件是它的类型，然后是类别，然后是具体的。而新式命名约定的人却被困在试图记住他们为该文本框命名的内容。

The original specification for controls is here (archived).

【讨论】：

同意。这实际上是我不再使用此语法的唯一原因，这仅仅是因为设计器生成的东西的部分类导致使用和声明之间的脱节。

是否有资源可能显示控件的“正确”前缀？对于 TextBox，我看到 txt、tb 和 tbx，所以我永远不确定什么是正确的。

@Neil：为什么需要缩写？将 button1 重命名为 btnUserEmail 比 buttonUserEmail 需要更多的工作（击键）。我绝对同意你的逻辑，但是 txt 不是控件的类型；文本框是。

那篇MS支持文章最后只在“适用于”中列出了VB4/VB6语言。也许不是现代 .NET 开发的最佳参考。

这是我用于命名约定的，但我认为最重要的想法是团队中的每个开发人员都使用相同的！

【参考方案2】：

我用：

TextBox nameTextBox;

就像我会使用的那样：

MailAddress homeAddress;

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

string fullName;

不是：

string fullNameString;

因为“字符串”不能描述对象所代表的内容，而只是描述它的存储方式。

【讨论】：

美丽的解释。如果您有一个名称类 (BigNameClass)，其中包含人名的一部分（前缀、名字、姓氏、中间名首字母、后缀），您会怎么做 那么您会使用 fullNameBigNameClass 吗？创建标准的一个困难部分是在哪里划清此类决定的界限。

谢谢。是的，我遇到了这个确切的问题。大多数属于“BigNameClass”类别的事物往往属于“AdjectiveAdjectiveAdjectiveAdjectiveNoun”模式。所以我倾向于将其简化为“fullNameNoun”或“fullNameAdjectiveNoun”......就像我将“MailAddress”简化为“Address”一样。

+1。我就是这样做的，感觉更好:)

基于控件的字段和参数怎么样？

【参考方案3】：

与 .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

等等，无穷无尽。后缀是什么并不重要，只要它们一致且具有描述性即可。

【参考方案4】：

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

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

我更喜欢匈牙利符号，因为我的所有 UI 控件在 intelisense 中都显示在一个块中。 “用户体验”的 UX。如果您将控件从文本框更改为组合框或其他内容也很好，因为名称不会改变。

【参考方案5】：

我希望有人能成为这个主题的权威，并按原样告诉它，并开始执行它......对我来说最糟糕的事情是当人们在同一个应用程序中混淆它，或者更糟糕的是同一个类。

我看到一些非常可怕的东西，txtName、NameTextBox、name 和 textBox1 都用在同一个表单上……呸。

在我工作的地方，我们有一份标准文档，告诉我们如何去做，在哪里做，我认为只有 20% 的人甚至愿意尝试和遵守。

如果 Fxcop 对我大喊大叫，我通常会做出改变。

http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29

Capitalization Styles

请注意： 对于大多数标识符，Microsoft .NET 建议使用 UpperCamelCase（又名“Pascal 样式”）。 （参数建议小写）。

【讨论】：

+1 用于链接 Microsoft 的 .NET 命名建议。

【参考方案6】：

关于命名约定，最重要的是选择有意义的东西，获得各方的共识，并像生命依赖它一样坚持下去。

至于使用哪个约定，我会投票给这个：

TextBox name

它很短，并且具有作为标识符的语义价值。至于标识符的 type，我会依靠 Visual Studio 来告诉你，因为它往往擅长这种事情。

【讨论】：

我同意，否则你会冒 txtName 实际上是一个组合框的风险，等等。

【参考方案7】：

我将所有 UI 元素命名为 TypeDescriptor。按照你的例子，TextBoxName。

【讨论】：

这是我遵循的，只是我倾向于将第一个字母小写，只是因为我觉得它更悦目。所以对我来说它是 textBoxName

这个约定很有帮助，因为它有效地将 GUI 对象放在与其他字段不同的命名空间中。我的登录代码可能有几个变量名为userName 或password，但不会与TextUserName 和TextPassword 混淆。

这对我来说没有意义，因为在英语中我们更喜欢AdjectiveNoun。例如，UserName，而不是 NameUser。所以TextBoxName 将是文本框的名称（它是TextBox 类型的名称或名词）。 NameTextBox 是正确的：它是一个 TextBox 类型，或者对于 Name，就像 UserName 是一个 Name 类型，或者对于 User。

@ErikE 也许是为了智能感知？如果您输入 TextBox、txt（或您喜欢的后缀），您可以从那里看到所有文本框控件。

@Hacki 是的，但这只是组织意义的一种可能方式。 也许您会发现按照它们引用的控件类型来组织所有符号很有用，但是您完全失去了按另一个值排序的能力。如果您想让NameTextbox、NameLabel、NameEditButton 和NameActiveCheckBox 彼此靠近怎么办？一起查看所有文本框控件不会自动获胜。这取决于你看重什么。我根本不重视控件的类型——我重视它的语义。

【参考方案8】：

我使用 Hungation 表示法，但略有不同。

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

当应用程序能够吸引来自不同位置的用户时，事情就变得复杂了。那是不同的控制。所以我开始以它们所在的位置命名我的控件，并且仍然使用匈牙利符号。

例如：tabSchedAddSchedTxbAdress 表示 txbAddress 是一个可以插入地址的文本框，位于调度选项卡控件的添加调度选项卡上。 这样我就可以很容易地找到控件，而且当我简单地键入“btn”时，我不会立即获得来自整个用户界面的大量按钮。

当然，这只是为了帮助自己。我不知道这样的最佳做法。但是，它有很大帮助。

摩苏'

【参考方案9】：

我最近一直在与一个从 MFC (6.0 ...) 迁移的团队合作。在那里他们会有类似的东西

CString Name;
CEdit ctlName;

最简单的迁移方法是使用类似

TextBox ctlName

这足以提醒变量是控件而不是控件的值。

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

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

【参考方案10】：

我倾向于使用 c_typeName（请注意 type 和 Name 是不同的），例如c_tbUserEmail 用于用户应在其中键入他/她的电子邮件的文本框。我发现它很有用，因为当有很多控件时，很难在数英里长的智能感知列表中找到它们，因此通过添加 c_ 前缀，我可以轻松查看该表单中的所有控件。

【参考方案11】：

这种匈牙利/VB6 命名的疯狂需要停止。

如果 Microsoft 真的希望您根据控件类型来命名控件，那么当您将控件添加到 web/win 表单时，为什么 Visual Studio 不自动添加“txt”或“btn”？

【讨论】：

但那还有什么办法呢？

我个人为它的用途命名一个文本框：名称、用户名、密码等。除非它与某些类成员冲突，否则添加一个后缀，例如：nameTextBox 或 nameInput。

这是讽刺吗？当您将控件添加到表单时，Visual Studio确实按类型命名控件。

【参考方案12】：

您拥有来自 Microsoft 的 Guidelines for Names。我不会遵循所有内容，但这是一个很好的起点

【参考方案13】：

我使用匈牙利符号，这样可以很容易地在大页面中找到控件。

【参考方案14】：

对于我不打算在代码中使用的元素，我只是让设计人员为我处理；如果它们确实成为我的代码中使用的东西，它们就会被更改为有意义的东西，并且恰好是 descriptionType (nameTextBox)。如果提供足够的信息，这就是设计人员创建它们的方式（查看菜单项——“退出”变为 exitMenuItem）。

【参考方案15】：

我自己的做法是：键入_contextDescriptionType。 例如：

TextBox _searchValueTextBox

无论如何，命名约定要么过于个人化，要么是由一般规则强加的。无论如何，它都应该记录在某个地方，以便所有项目开发人员都可以轻松访问。

【参考方案16】：

我相信命名约定的存在可以简化开发人员的编码工作并有助于可管理性。据我了解，应遵循任何有助于轻松访问的名称。

我看到了许多采用不同方法的 cmets，但我在项目中发现的最好的方法是为 control 的前三个名称添加前缀。采用这种方法有很多原因。

Intellisense 会将所有相同的类型组合在一起。 表单属性窗口也会显示所有相同的排序控件 在复杂表单上，您可以轻松识别您正在处理标签或文本框（例如 lblAccounts 和 txtAccounts） 新用户可以轻松处理编码。 假设我在同一个表单上有 accountLst、accountlbl、accounttxt、accountgrd、accountChk 控件。

在编码时，开发人员始终知道他正在访问文本框或标签。他不清楚其他开发人员使用了什么名称。因此，只需编写“lbl”，intellisens 就可以选择所有标签列表，如果您使用了 #5 中使用的方法，那么 intellisense 将使用 acc 带来所有控件。我很少看到控制名称以“帐户”左右开头的循环。这意味着它对任何罕见的事件都无济于事。

我的赌注是做一些有助于其他开发人员轻松理解代码的事情。因为随着您在运营商中长大，您不会总是编码，其他人会来坐您的位子。

选择是你的，你想要的方式！

【参考方案17】：

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