I use the old school hungarian... txt for TextBox, btn for Button, followed by a generalized word, then a more specific word. i.e.:
btnUserEmail
Have had a lot of people say things like "omg thats so old, VB6 calling!" But in a UI Rich winforms app, I can find and modify things quicker because usually the first thing you know about a control is it's type, then it's category, then get specific. While the newer style naming convention guys are stuck trying to remember what they named that text box.
The reason for this is that in these cases "TextBox" and "Address" is descriptive of what the object represents, not how it is stored or used. But in another case like storing a person's full name I would use:
string fullName;
Not:
string fullNameString;
Because "String" is not descriptive of what the object represents, but only how it is stored.
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
等等无穷无尽。 后缀是什么并不重要，只要它们一致且具有描述性即可。
Same convention as everything else in .NET: camel case descriptive name only, optionally followed by a suffix if you need to distinguish different classes for the same logical "thing". For example:
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
and so on ad infinitum. It really doesn't matter what the suffixes are as long as they are consistent and descriptive.
TextBox uxName = new TextBox();
Label uxNameLabel = new Label();
Button uxAccept = new Button();
I prefer this to Hungarian notation since all of my UI controls show up in one block in intelisense. UX for "User eXperience". It's also nice if you change a control from a textbox to a combobox or something, as the name won't change.
请注意： Microsoft .NET 建议大多数标识符使用 UpperCamelCase（又名“Pascal 样式”）。 （参数建议使用小驼峰命名法）。
I wish someone would become the authority on this subject and just tell it like it is, and start enforcing it... The worst thing to me is when people mix it up in the same application or worse yet same class.
I've see some pretty horrible stuff with txtName, NameTextBox, name and textBox1 all used on the same form... yuck.
Where I work we have a standards document that tells us how to do it, where to do it, and I think only 20% of the people even care to try and conform.
I usually will change something if Fxcop yells at me.
它很短并且具有作为标识符的语义价值。 至于标识符的类型，我将依靠 Visual Studio 来告诉您，因为它往往擅长这类事情。
The most important thing about naming conventions is to choose something that makes sense, get a consensus from all parties, and stick to it like your life depended on it.
As for which convention to use I would vote for this one:
TextBox name
It is short and has semantic value as an identifier. As for the type of the identifier I would rely on Visual Studio to tell you that as it tends to be good at that sort of thing.
I use the Hungation notation with one little difference.
I now work on a project that has quite a rich UI. So finding, with Intellisense, a button called, let's say, btnGetUsers its very easy.
Things get's complicated when the application is able to get users from different locations. That is different controls. So I started to name my controls after where they are located and still use the Hungarian notation.
As an example: tabSchedAddSchedTxbAdress means that txbAddress is a text box where an address can be inserted and is located on the Add Scheduling tab from the Scheduling Tab Control. This way I can find controls very easy and, when I type simply "btn" I don't get, at once, a lot of buttons from all over the user interface.
Of course this is just to help myself. I'm not aware of such a best practice. However it helps a lot.
I've been working with a team lately that is moving from MFC (6.0 ...). There they would have something like
CString Name;
CEdit ctlName;
The easiest way to migrate has been to use something like
TextBox ctlName
It's just enough of a reminder that the variable is the control and not the value of the control.
I think including the type as a part of the name is just OLD.
-- edit -- Another benefit is that all of the controls are grouped together when navigating. If the actual type were used, the ComboBox controls would be quite far from the TextBox controls.
I tend to use c_typeName (please note that type and Name are different), e.g. c_tbUserEmail for a TextBox into which the user should type in his/her e-mail. I find it useful because when there are a lots of a controls, it can be hard to find them in the miles long intellisense list, so by adding the c_ prefix I can easily see all controls in that form.
如果 Microsoft 确实希望您根据控件的类型命名控件，那么当您将控件添加到 web/win 表单时，为什么 Visual Studio 不自动添加“txt”或“btn”呢？
This Hungarian/VB6-naming insanity needs to stop.
If Microsoft really wanted you to name your controls based on their type then why doesn't Visual Studio automatically tack on the 'txt' or 'btn' when you add the control to your web/win Form?
For the elements that I don't plan on using in my code, I just let the designer handle it for me; if they do become something used in my code, they're changed to something meaningful and that happens to be descriptionType (nameTextBox). It's how the designer creates them if given enough information (check out menu items -- "Exit" becomes exitMenuItem).
My own practice is: Type _contextDescriptionType. E.g.:
TextBox _searchValueTextBox
Anyway naming convention is either too personal or imposed by general rules. In any case it should be documented somewhere so that all project developers can easyly access.
I believe naming convention exist to ease the developer coding effort and helps in manageability. To my understand any name which is helpful in easy access should be followed.
I saw number of comments with different approach but the best i found in my projects are to prefix control's 1st three name. There are lots of reason behind following this approach.
Intellisense would bring all same type together.
Form property windows would also show all same control sorted
On complex forms you can easily identify you are dealing with label or textbox (eg. lblAccounts and txtAccounts)
A new user can easily deal with coding.
Imagine I have accountLst, accountlbl, accounttxt, accountgrd, accountChk controls on same form.
While coding, a developer always knows he is accessing text box or label. Where as he is not clear with what name the other developer has used. So by just writing "lbl" intellisens would bring all the label list to choose, where is if you have used approach used in #5 then intellisense would bring all controls using acc. I rarely saw doing some loop with control name start with "account" or so. This means it would not help in any rare incident.
My bet is to do things which help in understanding code easily for other developer. Because as you grow up in your carrier, you would not always do coding, some other person would come and take your seat.
If there is a good separation of concerns in an application design, I guess there will be no need for naming buttons as LoginButton, LoginBtn or btnLogin. If the owner of the object is a UI element thus let's call it Login and if the owner is not a UI element then the object is in a wrong place.
发布评论
评论（17）
我使用老式匈牙利语... txt 表示文本框，btn 表示按钮，后面跟着一个概括的单词，然后是一个更具体的单词。 即：
有很多人说过这样的话“天哪，太旧了，VB6 调用！” 但在 UI Rich winforms 应用程序中，我可以更快地找到和修改内容，因为通常你知道的第一件事关于控件，首先是它的类型，然后是它的类别，然后是具体的。 虽然采用较新的样式命名约定，但人们仍然试图记住他们为该文本框命名的内容。
控件的原始规范在这里（已存档）。
I use the old school hungarian... txt for TextBox, btn for Button, followed by a generalized word, then a more specific word. i.e.:
Have had a lot of people say things like "omg thats so old, VB6 calling!" But in a UI Rich winforms app, I can find and modify things quicker because usually the first thing you know about a control is it's type, then it's category, then get specific. While the newer style naming convention guys are stuck trying to remember what they named that text box.
The original specification for controls is here (archived).
我使用：
就像我会使用：
这样做的原因是，在这些情况下，“TextBox”和“Address”描述的是对象所代表的内容，而不是它的存储或使用方式。 但在另一种情况下，比如存储一个人的全名，我会使用：
不：
因为“String”不能描述对象所代表的内容，而只能描述它的存储方式。
I use:
Just like I would use:
The reason for this is that in these cases "TextBox" and "Address" is descriptive of what the object represents, not how it is stored or used. But in another case like storing a person's full name I would use:
Not:
Because "String" is not descriptive of what the object represents, but only how it is stored.
与 .NET 中其他所有内容相同的约定：仅使用驼峰式大小写描述性名称，如果需要区分同一逻辑“事物”的不同类，则可以选择后跟后缀。 例如：
等等无穷无尽。 后缀是什么并不重要，只要它们一致且具有描述性即可。
Same convention as everything else in .NET: camel case descriptive name only, optionally followed by a suffix if you need to distinguish different classes for the same logical "thing". For example:
and so on ad infinitum. It really doesn't matter what the suffixes are as long as they are consistent and descriptive.
这不是我的发明，但我喜欢它：
与匈牙利表示法相比，我更喜欢这种表示法，因为我的所有 UI 控件都显示在智能感知中的一个块中。 UX“用户体验”。 如果您将控件从文本框更改为组合框或其他控件，这也很好，因为名称不会更改。
This is not my invention, but I like it:
I prefer this to Hungarian notation since all of my UI controls show up in one block in intelisense. UX for "User eXperience". It's also nice if you change a control from a textbox to a combobox or something, as the name won't change.
我希望有人能成为这个主题的权威，然后按原样讲述它，然后开始执行它......对我来说最糟糕的事情是当人们将它混合在同一个应用程序或更糟糕的同一类中时。
我看到一些非常可怕的东西，其中 txtName、NameTextBox、name 和 textBox1 都在同一个表单上使用......恶心。
在我工作的地方，我们有一份标准文档，告诉我们如何做、在哪里做，我认为只有 20% 的人愿意尝试并遵守。
如果 Fxcop 对我大喊大叫，我通常会改变一些东西。
http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29
大写样式
请注意：
Microsoft .NET 建议大多数标识符使用 UpperCamelCase（又名“Pascal 样式”）。 （参数建议使用小驼峰命名法）。
I wish someone would become the authority on this subject and just tell it like it is, and start enforcing it... The worst thing to me is when people mix it up in the same application or worse yet same class.
I've see some pretty horrible stuff with txtName, NameTextBox, name and textBox1 all used on the same form... yuck.
Where I work we have a standards document that tells us how to do it, where to do it, and I think only 20% of the people even care to try and conform.
I usually will change something if Fxcop yells at me.
http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29
Capitalization Styles
Note that:
Microsoft .NET recommends UpperCamelCase (aka "Pascal Style") for most identifiers. (lowerCamelCase is recommended for parameters).
关于命名约定，最重要的是选择有意义的东西，获得各方的共识，并坚持下去，就像你的生活依赖它一样。
至于使用哪种约定，我会投票给这个：
它很短并且具有作为标识符的语义价值。 至于标识符的类型，我将依靠 Visual Studio 来告诉您，因为它往往擅长这类事情。
The most important thing about naming conventions is to choose something that makes sense, get a consensus from all parties, and stick to it like your life depended on it.
As for which convention to use I would vote for this one:
It is short and has semantic value as an identifier. As for the type of the identifier I would rely on Visual Studio to tell you that as it tends to be good at that sort of thing.
我将所有 UI 元素命名为 TypeDescriptor。 按照您的示例，
TextBoxName。I name all my UI elements TypeDescriptor. Following your example,
TextBoxName.我使用 Hungation 表示法，但有一点区别。
我现在正在从事一个具有相当丰富的用户界面的项目。 因此，使用 Intellisense 查找一个名为 btnGetUsers 的按钮非常容易。
当应用程序能够从不同位置获取用户时，事情就会变得复杂。 那就是不同的控制。 因此，我开始根据控件的位置来命名它们，并仍然使用匈牙利表示法。
例如： tabSchedAddSchedTxbAdress 表示 txbAddress 是一个可以插入地址的文本框，位于“计划”选项卡控件的“添加计划”选项卡上。
通过这种方式，我可以非常轻松地找到控件，并且当我简单地键入“btn”时，我不会立即从整个用户界面中看到很多按钮。
当然这只是为了帮助自己。 我不知道这样的最佳实践。 然而它有很大帮助。
摩苏'
I use the Hungation notation with one little difference.
I now work on a project that has quite a rich UI. So finding, with Intellisense, a button called, let's say, btnGetUsers its very easy.
Things get's complicated when the application is able to get users from different locations. That is different controls. So I started to name my controls after where they are located and still use the Hungarian notation.
As an example: tabSchedAddSchedTxbAdress means that txbAddress is a text box where an address can be inserted and is located on the Add Scheduling tab from the Scheduling Tab Control.
This way I can find controls very easy and, when I type simply "btn" I don't get, at once, a lot of buttons from all over the user interface.
Of course this is just to help myself. I'm not aware of such a best practice. However it helps a lot.
Mosu'
我最近一直在与一个从 MFC（6.0 ...）迁移的团队一起工作。 在那里他们会有类似的东西
最简单的迁移方法是使用类似的东西
这足以提醒变量是控件而不是控件的值。
我认为将类型作为名称的一部分已经过时了。
- 编辑 -
另一个好处是导航时所有控件都组合在一起。 如果使用实际类型，ComboBox 控件将与 TextBox 控件相距很远。
I've been working with a team lately that is moving from MFC (6.0 ...). There they would have something like
The easiest way to migrate has been to use something like
It's just enough of a reminder that the variable is the control and not the value of the control.
I think including the type as a part of the name is just OLD.
-- edit --
Another benefit is that all of the controls are grouped together when navigating. If the actual type were used, the ComboBox controls would be quite far from the TextBox controls.
我倾向于使用 c_typeName （请注意类型和名称不同），例如 c_tbUserEmail 用于用户应在其中输入他/她的电子邮件的文本框。 我发现它很有用，因为当有很多控件时，很难在长达数英里的智能感知列表中找到它们，因此通过添加 c_ 前缀，我可以轻松查看该形式的所有控件。
I tend to use c_typeName (please note that type and Name are different), e.g. c_tbUserEmail for a TextBox into which the user should type in his/her e-mail. I find it useful because when there are a lots of a controls, it can be hard to find them in the miles long intellisense list, so by adding the c_ prefix I can easily see all controls in that form.
这种匈牙利/VB6 命名的疯狂行为需要停止。
如果 Microsoft 确实希望您根据控件的类型命名控件，那么当您将控件添加到 web/win 表单时，为什么 Visual Studio 不自动添加“txt”或“btn”呢？
This Hungarian/VB6-naming insanity needs to stop.
If Microsoft really wanted you to name your controls based on their type then why doesn't Visual Studio automatically tack on the 'txt' or 'btn' when you add the control to your web/win Form?
您拥有 Microsoft 提供的名称指南。 我没有遵循所有内容，但这是一个很好的起点
You have the Guidelines for Names from Microsoft. I dot not follow everything, but it's a good starting point
我使用匈牙利表示法，这样可以轻松地在大页面中找到控件。
I use Hungarian notation, that makes easy to find controlls in large pages.
对于我不打算在代码中使用的元素，我只是让设计师帮我处理； 如果它们确实成为我的代码中使用的内容，它们就会更改为有意义的内容，并且恰好是descriptionType（nameTextBox）。 如果给定了足够的信息，这就是设计者创建它们的方式（查看菜单项——“退出”变为 exitMenuItem）。
For the elements that I don't plan on using in my code, I just let the designer handle it for me; if they do become something used in my code, they're changed to something meaningful and that happens to be descriptionType (nameTextBox). It's how the designer creates them if given enough information (check out menu items -- "Exit" becomes exitMenuItem).
我自己的做法是：输入_contextDescriptionType。
例如：
无论如何，命名约定要么太个人化，要么是由一般规则强加的。 无论如何，它应该记录在某个地方，以便所有项目开发人员都可以轻松访问。
My own practice is: Type _contextDescriptionType.
E.g.:
Anyway naming convention is either too personal or imposed by general rules. In any case it should be documented somewhere so that all project developers can easyly access.
我相信命名约定的存在是为了减轻开发人员的编码工作并有助于提高可管理性。 据我了解，任何有助于轻松访问的名称都应该遵循。
我看到了许多不同方法的评论，但我在项目中发现的最好的方法是为控件的前三个名称添加前缀。 遵循这种方法背后有很多原因。
在编码时，开发人员始终知道他正在访问文本框或标签。 他不清楚其他开发人员使用了什么名称。 因此，只需编写“lbl”intellisens 就会带来所有标签列表可供选择，如果您使用了#5 中使用的方法，那么 intellisense 会使用 acc 带来所有控件。 我很少看到用“帐户”左右开头的控件名称进行一些循环。 这意味着它对于任何罕见的事件都没有帮助。
我的赌注是做一些有助于其他开发人员轻松理解代码的事情。 因为当你在运营商中长大时，你不会总是进行编码，其他人会过来取代你的座位。
选择权在你，你想怎么走就怎么走！
I believe naming convention exist to ease the developer coding effort and helps in manageability. To my understand any name which is helpful in easy access should be followed.
I saw number of comments with different approach but the best i found in my projects are to prefix control's 1st three name. There are lots of reason behind following this approach.
While coding, a developer always knows he is accessing text box or label. Where as he is not clear with what name the other developer has used. So by just writing "lbl" intellisens would bring all the label list to choose, where is if you have used approach used in #5 then intellisense would bring all controls using acc. I rarely saw doing some loop with control name start with "account" or so. This means it would not help in any rare incident.
My bet is to do things which help in understanding code easily for other developer. Because as you grow up in your carrier, you would not always do coding, some other person would come and take your seat.
Choice is yours, which way you want!
如果应用程序设计中存在良好的关注点分离，我想就不需要将按钮命名为 LoginButton、LoginBtn 或 btnLogin。 如果对象的所有者是 UI 元素，那么我们将其称为 Login，如果所有者不是 UI 元素，则该对象位于错误的位置。
If there is a good separation of concerns in an application design, I guess there will be no need for naming buttons as LoginButton, LoginBtn or btnLogin. If the owner of the object is a UI element thus let's call it Login and if the owner is not a UI element then the object is in a wrong place.