C＃GUI命名约定的最佳做法？[关闭]

无论用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往往会违反这些规则或千差万别。我还没有看到任何专门针对GUI元素的Microsoft指南，而不仅仅是普通变量，甚至没有适用于控制台应用程序之外的示例。

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

我使用的是老式的匈牙利语... txt表示TextBox，btn表示Button，其后是广义词，然后是更具体的词。即：

btnUserEmail

已经有很多人说诸如“ omg thats old，VB6 call！”之类的话！ 但是在UI Rich winforms应用程序中，我可以更快地查找和修改内容，因为通常您对控件了解的第一件事是它的类型，然后是类别，然后变得具体。在使用较新的样式命名约定时，人们总是想记住他们命名该文本框的方式。

控件的原始规范在这里（存档）。

我用：

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

以此类推。只要后缀一致且具有描述性，后缀的名称实际上并不重要。

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

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

我更喜欢匈牙利表示法，因为我的所有UI控件都在intelisense中显示为一个块。用户体验的用户体验。如果将控件从文本框更改为组合框之类的东西也很好，因为名称不会更改。

我希望有人能够成为这个主题的权威，并像现在这样说，然后开始执行它。。。对我而言，最糟糕的是，人们在同一应用程序或更糟的同一类中混合使用它。

我已经看到了txtName，NameTextBox，name和textBox1都以相同的形式使用的一些非常可怕的东西。

在我工作的地方，我们有一个标准文件来告诉我们如何做，在哪里做，而且我认为只有20％的人甚至在乎尝试并遵循。

如果Fxcop对我大吼大叫，我通常会改变一些东西。

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

大写样式

请注意：Microsoft .NET建议大多数标识符使用UpperCamelCase（又名“ Pascal样式”）。（建议使用lowerCamelCase作为参数）。

命名约定最重要的事情是选择有意义的东西，征得各方的一致同意，并坚持下去，就像您的生活依赖它一样。

至于使用哪种约定，我将为此投票：

TextBox name

它很短，具有语义值作为标识符。至于标识符的类型，我将依靠Visual Studio告诉您，因为它往往擅长于此类事情。

我使用的是Hungation表示法，只有一点点不同。

现在，我在一个具有丰富UI的项目上工作。因此，使用Intellisense查找一个名为btnGetUsers的按钮非常简单。

当应用程序能够吸引来自不同位置的用户时，事情就变得很复杂。那是不同的控件。因此，我开始以控件的位置命名，但仍使用匈牙利符号。

例如：tabSchedAddSchedTxbAdress意味着txbAddress是一个文本框，可以在其中插入地址，并且位于“计划”选项卡控件的“添加计划”选项卡上。这样，我可以很容易地找到控件，而当我只键入“ btn”时，不会一次从整个用户界面中得到很多按钮。

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

摩苏

我将所有UI元素都命名为TypeDescriptor。按照您的示例，TextBoxName。

我最近一直在与一个从MFC（6.0 ...）开始转移的团队合作。那里他们会有类似的东西

CString Name;
CEdit ctlName;

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

TextBox ctlName

提醒您，变量是控件，而不是控件的值。

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

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

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

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

如果Microsoft确实希望您根据控件的类型来命名控件，那么在将控件添加到Web / Win窗体中时，Visual Studio为什么不自动添加“ txt”或“ btn”？

您有Microsoft的《名称指南》。我不会跟随一切，但这是一个很好的起点

我使用匈牙利表示法，可以轻松在大页面中找到控件。

对于我不打算在代码中使用的元素，我只让设计者为我处理；如果它们确实成为我的代码中使用的东西，则它们将变为有意义的东西，并且恰好是descriptionType（nameTextBox）。如果给定足够的信息，这就是设计器创建它们的方式（签出菜单项-“ Exit”变成exitMenuItem）。

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

TextBox _searchValueTextBox

无论如何，命名约定要么太个人化，要么由一般规则强加。无论如何，都应该将其记录在某处，以便所有项目开发人员都可以轻松访问。

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

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

1. Intellisense会将所有相同的类型整合在一起。
2. 窗体属性窗口还将显示所有相同的控件排序
3. 在复杂的表格上，您可以轻松地确定自己正在处理标签或文本框（例如lblAccounts和txtAccounts）
4. 新用户可以轻松处理编码。
5. 想象一下，我在同一表格上有accountLst，accountlbl，accounttxt，accountgrd，accountChk控件。

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

我的赌注是做一些有助于其他开发人员轻松理解代码的事情。因为随着您在承运人中成长，您将不会总是进行编码，因此会有其他人来坐下来。

选择是您的，您想要哪种方式！

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