C＃GUI命名约定的最佳实践？
无论是用WinForms还是XAML编写的graphics用户界面，在我看到的项目之间似乎都有着最广泛的命名约定。 对于一个人的名字简单的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元素，而不是只是正常的variables，甚至可以应用在控制台应用程序之外的例子。
在GUI中命名元素的最佳做法是什么？
我使用旧的匈牙利语… txt文本框，btn的button，其次是一个广义的词，然后一个更具体的词。 即：
btnUserEmail
有很多人说过“那么老，VB6叫！ 但是在一个UI丰富的winforms应用程序中，我可以更快地find和修改东西，因为通常情况下，您首先了解的是控件的types，然后是类别，然后获取具体信息。 虽然新的风格命名约定的家伙坚持试图记住他们命名该文本框。
我用：
TextBox nameTextBox;
就像我会使用：
MailAddress homeAddress;
原因是在这些情况下，“文本框”和“地址”是描述对象代表什么，而不是如何存储或使用。 但是在另一个例子中，像存储一个人的全名，我会使用：
string fullName;
不：
string fullNameString;
因为“string”不描述对象所代表的内容，而只是描述对象的存储方式。
与.NET中的所有其他规则相同：camel case仅限描述性名称，如果需要为相同的逻辑“thing”区分不同的类，可以select后缀后缀。 例如：
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的一个块中。 UX的“用户体验”。 如果你把一个控件从一个文本框改成一个combobox或者其他的东西，这个名字也不会改变，这也是很好的。
关于命名规则最重要的是select有意义的东西，得到各方的共识，并坚持下去，就像你的生活依赖于它。
至于使用哪个公约，我会投这个票：
TextBox name
它是简短的，具有语义价值作为一个标识符。 至于标识符的types ，我会依靠Visual Studio来告诉你，因为它往往擅长这样的事情。
我希望有人会成为这个问题上的权威，只是把它说出来，然后开始执行它。对我来说，最糟糕的是，当人们把它们混淆在同一个应用程序中，或者更糟的是同一个类时。
我看到一些相当可怕的东西与txtName，NameTextBox，名称和textBox1所有使用相同的forms… yuck。
在哪里工作，我们有一个标准文件，告诉我们该怎么做，在哪里做，我认为只有20％的人甚至在意尝试和遵守。
如果Fxcop嚷嚷我，我通常会改变一些事情。
http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29
大写样式
请注意：Microsoft .NET为大多数标识符推荐UpperCamelCase（又名“Pascal样式”）。 （推荐使用lowerCamelCase作为参数）。
我将所有的UI元素命名为TypeDescriptor。 以您的示例为例， TextBoxName 。
我一直在与最近从MFC（6.0 …）移动的团队合作。 在那里他们会有类似的东西
CString Name; CEdit ctlName;
最简单的迁移方式就是使用类似的东西
TextBox ctlName
这只是提醒，variables是控制，而不是控制的价值。
我认为包括types作为名称的一部分只是旧的。
– 编辑 – 另一个好处是所有的控制在浏览时被分组在一起。 如果使用实际的types，ComboBox控件将远离TextBox控件。
这匈牙利/ VB6命名疯狂需要停止。
如果微软真的希望你根据他们的types命名你的控件，那么当你把控件添加到你的web / win表单的时候，Visual Studio为什么不自动使用“txt”或者“btn”呢？
我用一个有点区别的Hungation符号。
我现在正在开发一个拥有丰富用户界面的项目。 所以用Intellisensefind一个叫做button的button，比方说btnGetUsers很简单。
当应用程序能够从不同位置获取用户时，情况变得复杂。 这是不同的控制。 所以我开始在他们所在的位置命名我的控制，并仍然使用匈牙利符号。
例如：tabSchedAddSchedTxbAdress表示txbAddress是一个文本框，其中可以插入地址，并位于“调度”选项卡控件的“添加调度”选项卡上。 这样我就可以很容易地find控件，当我input“btn”时，我不会立即从整个用户界面获得很多button。
当然这只是为了帮助自己。 我不知道这样的最佳做法。 但是它有很大的帮助。
Mosu”
我使用匈牙利符号，这使得在大页面中容易find控制。
对于我不打算在代码中使用的元素，我只是让devise人员为我处理; 如果他们确实成为我的代码中使用的东西，他们会改变到有意义的东西，这恰好是descriptionType （nameTextBox）。 这是devise师如果给予足够的信息（检查菜单项 – “退出”成为exitMenuItem）如何创build它们。
我自己的做法是：键入_contextDescriptionType。 例如：
TextBox _searchValueTextBox
无论如何，命名约定不是太私人化，就是一般的规则。 在任何情况下，都应该在某个地方logging下来，以便所有项目开发人员都可以轻松访问。
我倾向于使用c_typeName（请注意，types和名称是不同的），例如c_tbUserEmail为用户应该在其中input他/她的电子邮件的文本框。 我觉得它很有用，因为当有很多控件时，在英里长的intellisense列表中很难find它们，所以通过添加c_前缀我可以很容易地看到所有的控件。
您有“微软名称指南” 。 我没有遵循一切，但这是一个很好的起点
我相信命名约定的存在可以减轻开发人员的编码工作，并有助于pipe理。 据我了解，任何有助于访问的名字都应该遵循。
我看到不同方法的评论数量，但最好的我在我的项目中发现是前缀控制的前三名。 遵循这种方法有很多原因。
- 智能感应将所有相同的types放在一起。
- 窗体属性窗口也将显示所有相同的控制sorting
- 在复杂的表单上，您可以轻松识别您正在处理的标签或文本框（例如。lblAccounts和txtAccounts）
- 新用户可以轻松处理编码。
- 想象一下，我有相同的formsaccountLst，accountlbl，accounttxt，accountgrd，accountChk控件。
编码时，开发人员总是知道他正在访问文本框或标签。 在哪里，他不清楚其他开发者使用了什么名字。 所以只要写“lbl”，intellisens会带来所有的标签列表，如果你使用了＃5中使用的方法，那么intellisense会使用acc来带来所有的控制。 我很less看到做一些循环控制名称开始“帐户”左右。 这意味着这对任何罕见的事件都无济于事。
我敢打赌，做的事情有助于为其他开发人员轻松理解代码。 因为随着你在运营商的成长，你不会一直在做代码，有的人会来坐下。
select是你的，你想要哪种方式！
如果在应用程序devise中存在很好的关注点分离问题，我想不需要将button命名为LoginButton，LoginBtn或btnLogin。 如果对象的所有者是一个UI元素，那么我们称它为Login，如果所有者不是一个UI元素，那么这个对象就位于错误的地方。
