GUIs, whether written in WinForms or XAML, seem to have the most widely differing naming conventions between projects I see. For a simple TextBox
for a person's name, I've seen various naming conventions:
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
I abide by the StyleCop rules for all my .cs files normally, and see others do so as well, but the GUI tends to break these rules or vary wildly. I haven't seen any Microsoft guidelines that specifically refer to GUI elements instead of just normal variables, or even examples that would apply outside of a console application.
What are the best practices for naming elements in a GUI?
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.
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.
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.
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.
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.