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

我用的是古匈牙利语…文本框为TXT,按钮为BTN,后面是一个通用词,然后是一个更具体的词。即。:

btnUserEmail

有很多人说 “天哪,那太老了,vb6呼叫!” 但是在一个富用户界面的Winforms应用程序中,我可以更快地找到和修改内容,因为通常你对控件的第一个了解是它的类型,然后是类别,然后具体化。虽然新的命名约定风格的人一直在努力记住他们命名的文本框。

The original specification for controls is here (archived).

我使用:

TextBox nameTextBox;

就像我会用:

MailAddress homeAddress;

这是因为在这些情况下,“文本框”和“地址”描述的是对象所代表的内容,而不是对象的存储或使用方式。但在另一种情况下,如存储某人的全名,我会使用:

string fullName;

不是:

string fullNameString;

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

与.NET中其他所有内容的约定相同:仅限camel大小写描述性名称,如果需要为同一逻辑“thing”区分不同的类,可以选择后跟后缀。例如:

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控件都显示在Intelisen的一个块中。用户体验。如果您将控件从文本框更改为组合框或其他类型,也很好,因为名称不会更改。

我希望有人能成为这个问题的权威,像这样告诉它,并开始执行它…对我来说最糟糕的是,当人们把它混合在同一个应用程序中,或者更糟的是,在同一个类中。

我看到一些TxtName、NameTextBox、Name和TextBox1都在同一表单上使用的非常可怕的东西…讨厌。

在我工作的地方,我们有一个标准文件告诉我们如何去做,在哪里去做,我认为只有20%的人愿意尝试去遵守。

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

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

Capitalization Styles

注意: 对于大多数标识符,Microsoft.NET建议使用大写字母(又称“pascal样式”)。(参数建议使用较低的酶)。

关于命名约定,最重要的是选择一些有意义的东西,从所有各方获得一致意见,并像你的生活依赖于它一样坚持下去。

关于使用哪一公约,我将投票赞成这一公约:

TextBox name

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

我用了一点区别的符号。

我现在在一个拥有丰富用户界面的项目上工作。因此,使用智能感知,找到一个名为btngetus的按钮非常容易。

当应用程序能够从不同的位置获取用户时,事情就会变得复杂起来。这是不同的控制。所以我开始根据控件的位置命名它们,并且仍然使用匈牙利符号。

例如:tabscheddschedtxbaddress意味着txbaddress是一个可以插入地址的文本框,它位于“日程安排”选项卡控件的“添加日程安排”选项卡上。 这样我就可以很容易地找到控件,而且,当我简单地键入“btn”时,我不会立即从整个用户界面上获得许多按钮。

当然,这只是为了帮助我自己。我不知道这样的最佳实践。不过,这有很大帮助。

Mosu

我将所有的UI元素命名为typescriptor。以你的例子为例, TextBoxName .

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

CString Name;
CEdit ctlName;

最简单的迁移方法是使用

TextBox ctlName

只要提醒你变量是控件而不是控件的值就足够了。

我认为把字体作为名字的一部分是很古老的。

--编辑—— 另一个好处是,导航时所有控件都分组在一起。如果使用的是实际类型,则组合框控件将远离文本框控件。

我倾向于使用c_type name(请注意,类型和名称是不同的),例如,c_tbuseremail用于用户应在其电子邮件中键入的文本框。我觉得它很有用,因为当有很多控件时,很难在英里长的IntelliSense列表中找到它们,因此通过添加C_u前缀,我可以很容易地看到该表单中的所有控件。

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

如果Microsoft真的希望您根据控件的类型命名控件,那么为什么在将控件添加到Web/Win表单时,Visual Studio不自动附加“txt”或“btn”?

我使用匈牙利符号,这使得在大的页面中很容易找到控件。

对于我不打算在代码中使用的元素,我只是让设计人员为我处理它;如果它们确实在我的代码中被使用,它们就会变成有意义的东西,而这恰好是 描述类型 (名称文本框)。如果提供足够的信息(签出菜单项--“exit”变为exitmenuitem),设计人员就会创建它们。

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

TextBox _searchValueTextBox

无论如何,命名约定要么太私人化,要么被一般规则强加。无论如何,它应该被记录在某个地方,这样所有的项目开发人员都可以轻松地访问。

你有 Guidelines for Names 来自Microsoft。我不是什么都懂,但这是一个很好的起点

我认为存在命名约定是为了简化开发人员的编码工作,并有助于管理。据我所知,任何有助于轻松访问的名称都应该遵循。

我看到了许多不同方法的注释,但在我的项目中,我发现最好的方法是给控件的前三个名称加前缀。遵循这种方法有很多原因。

1. IntelliSense将把所有相同的类型放在一起。
2. 窗体属性窗口还将显示所有排序的相同控件
3. 在复杂的表单上,您可以很容易地识别正在处理标签或文本框(例如lblaccounts和txtaccounts)
4. 新用户可以很容易地处理编码。
5. 假设我有accountlst、accountlbl、accounttxt、accountgrd、accountchk控件在同一个表单上。

编写代码时,开发人员总是知道他正在访问文本框或标签。因为他不清楚其他开发者使用了什么名字。因此,只要编写“lbl”intellisens,就可以选择所有标签列表,如果您使用了5中使用的方法,那么intellisense将使用acc带来所有控件。我很少看到用“account”开头的控件名执行循环。这意味着它在任何罕见的事件中都不会起作用。

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

选择权属于你,你想怎么做!

如果在应用程序设计中有一个很好的关注点分离,我想不需要将按钮命名为loginbutton、loginbtn或btnlogin。如果对象的所有者是一个ui元素,那么让我们称之为login,如果所有者不是ui元素,那么对象就在一个错误的位置。