wpf - textBoxEmployeeName 与 employeeNameTextBox

Question

您使用哪种命名约定，为什么？

我喜欢使用employeeNameTextBox，因为：

• 从英语的角度来看，这似乎更自然。
• 我发现使用 Intellisense 查找起来更容易。
• 该约定类似于用于事件（MouseClickEvent、MouseClickEventHandler）和依赖属性（VisiblityProperty）的约定。

注意：我使用的是全名而不是缩写（例如“tb”），因为它符合 MS 的命名约定，即避免使用缩写。

http://msdn.microsoft.com/en-us/library/ms229045.aspx

Answer 1

首先在名称中使用控件类型 (textBoxEmployeeName) 的唯一原因是为了便于使用 Intellisense 进行分组（然后所有文本框控件将一起显示）。除此之外，使用这种方式确实没有任何好处。我发现第二种方式（employeeNameTextBox）更具可读性并且个人更喜欢这种方式，但很多人仍然会首先使用控件类型，因为这是很长时间以来的方式。

Answer 2

命名变量非常重要。厚客户端视图约定似乎被赋予了短板。以下是我的想法：

1. 永远不要将实际业务价值的 getter 和 setter 放在您的视图中。不要这样做：

   public Name EmployeeName { get; set; }
   

2. 要获取或设置 EmployeeName，您的有状态代码应显式调用方法。这样做是因为它表明状态不存储在视图上，但可以从视图派生或转置到视图：

   public void SetEmployeeName(Name employeeName);
   public Name GetEmployeeName();
   

3. 匈牙利符号是愚蠢的。它在语言 <= VB6 中很有用，因为它们使用了变量类型的后期绑定。您必须保护自己，因为类型不匹配是运行时错误，而不是编译时错误。仅txtEmployeeName当您也将使用strEmployeeNameand时才使用intEmployeeNumber。

4. 如果模式名称的前缀与您的命名约定不一致，请不要为控件类型（表示模式）添加前缀。如果您不创建commandNameFormatting（而不是nameFormattingComamnd），则不要创建textBoxEmployeeName.

5. 您可能需要某种后缀，因为 EmployeeName 不能充分描述变量的用途。EmployeeName 文本框的目的是接收输入。EmployeeNameTextBox如果这让您感到舒适，您可以调用它，但调用它可能会更好EmployeNameInput。这有一个额外的好处，如果你有一个标签，很明显EmployeeNamePrompt（或EmployeeNameLabel）与文本框不同。如果没有某种描述性的后缀，您就没有很好的区分方法。

Answer 3

我（几乎）总是使用 [controltype] [descriptive name]。当我查看代码时，我想立即知道我正在处理哪种类型的控件，如果我不记得名称，智能感知可以帮助我。

仅使用描述性名称 (EmplyeeName) 对我不起作用。什么类型的控制？它是标签、文本框还是组合框？还是字符串？还是文件？控件或变量的类型始终是其中的一部分，这一点非常重要。

Answer 4

我通常尽量保持元素类型简短，后跟一个区别标签。我发现它可以快速传达元素的类型和用途：

txtEmployeeName;
lblEmployeeName;

Answer 5

我提出第三种选择：uiEmployeName。原因：

1. 这不是匈牙利语。你提到的两种符号都只是匈牙利语的味道。
2. 如果您将员工姓名文本框更改为列表框，则无需重命名变量。
3. 一切都在智能感知中很好地分组，而不涉及对象的类型。
4. 对象的名称紧跟其功能。它是一个面向用户的对象，用于获取员工姓名。

Answer 6

必读的是Jaime 发布的XAML 指南：

还在这里阅读更多

Answer 7

当我阅读它时，问题中提到的文章中链接到的文章（即Names of Resources）确实在末尾使用了控件类型FileMenu（ArgumentException尽管它不是控件）。

我个人的看法是，这也更具可读性，因为它是员工姓名文本框，因此应该命名为employeeNameTextBox，就像按顺序读取“文件菜单”一词一样。（尽管为了简洁起见，我用“Edit”代替了“TextBox”——我可能应该改掉这种习惯，使用与环境名称一致的控件名称。）

Answer 8

为什么不是员工姓名？说真的，当您的 IDE 已经提供了控件类型作为名称的一部分时，它如何帮助交付易于维护的代码？考虑Ottenger 的变量和类命名规则

ķ

Answer 9

WPF 特定的答案：根本没有名字。

为什么？因为如果您使用 WPF 进行开发，则不应命名您的控件。如果你是，你做错了什么。

WinForms 需要命名控件，因为它的数据绑定非常弱。WPF 解决了所有这些问题：控件本身可以指定其数据和行为，因此无需命名。

Answer 10

我想最好遵循 Microsoft 的对象命名约定，以便在 C# 和 Visual Basic 中命名您的控件。

Answer 11

我已经使用了 txtEmployeeName 和 employeeNameTextbox。像许多所示的帖子一样，这有助于分组。一个按控件类型（txtEmployeeName，txtManagerName）分组，而另一个可以将不同的相关控件组合在一起（employeeNameTextbox，employeePhoneTextbox，managerNameTextBox，managerPhoneTextbox）。在许多情况下，我发现后者在编码时更有用。

Answer 12

你应该做任何使你的代码可读和自我记录的事情。遵循硬性规定总是一个错误，因为它们几乎从不涵盖需要完成的所有方面。有指导方针（例如不使用匈牙利符号）并没有错，但更重要的是，无论是什么命名约定，您都必须与您的命名约定保持一致和清晰，而不是遵循互联网上的一些规则。

Answer 13

想法：

1. 避免编码/缩写。

2. 该名称应从相同范围内的相似名称中脱颖而出。使最独特的部分成为最左边的部分。我怀疑您有多个文本框，但只有一个是员工姓名。

3. 避免不必要的上下文。这个页面上的所有名字都是关于员工的吗？它是“员工”页面吗？那么 EmployeeName 是多余的。NameBox 或 NameControl 应该足够了。

4. 避免不必要的上下文：您有不是控件的名称吗？如果是这样，“Box”或“Control”很有用，否则就没那么多用了。

披露：我是“ottinger 命名规则”中的“ottinger”，也演变为“清洁代码”的第 2 章。请参阅http://agileinaflash.blogspot.com/2009/02/meaningful-names.html上的简短表格

Answer 14

我不推荐任何形式的匈牙利符号。textBoxEmployeeName 是匈牙利符号的一种形式。所以我支持使用employeeNameTextBox。

就我个人而言，我什至不费心使用 TextBox 这个词，因为这对变量来说并不重要。重要的是“员工”和“姓名”。添加单词 TextBox 不仅会将您锁定在某种类型中，而且还会使更改该类型变得更加困难，因为您需要更改名称以规范您的代码并使其正确。假设由于某种原因您将其作为 TextBox 开始，但后来您收到将其更改为 DropDownList 或其他类型的要求，现在您必须更新所有代码和 JavaScript 以使其显示为 DropDownList 而不是 TextBox。

忘记尝试键入变量名称并简单地命名它们要容易得多。您有智能感知和编译时错误检查是有原因的，为什么不使用它。

Answer 15

我会选择[controlType][DomainTerm]，在这种情况下是textBoxEmployeeName。原因是，在为您背后的 C# 代码编码时，比域特定术语更关心 UI 控件。UI(View) 端编码我们需要更快地识别/识别控件类型，这比域重要一点View side 中的特定名称，并且由于我们从“从左到右”阅读此命名约定是相关的。我通常使用 txtEmployeeName 或 cmpEmployeeType ，但根据 MS 指南，首选 textBox 而不是 txt

Answer 16

在 VB 中，我实际上喜欢使用 [ControlName]_[ControlType]。我不记得我是如何开始这样做的，但我想这是因为它感觉像是一个合乎逻辑的顺序。它还稍微简化了编码，因为代码建议是按控件描述而不是控件类型分组的。

我在 C# 中以相同的方式命名控件，只是我遵循 C# 对 camelCase 的偏好：[controlName]_[controlType]。

我也倾向于使用我自己的控件类型的缩写，尽管它们并不含糊。

例子：

VB： Save_Btn和NewFile_MItem（菜单项）

C#： save_btn和newFile_mItem

它对我有用，但当然每个程序员都有自己的风格。