textBoxEmployeeName vs employeeNameTextBox

Question

Which naming convention do you use and why?

I like to use employeeNameTextBox, because:

• It seems more natural from an English language perspective.

Answer 1

I have used both txtEmployeeName and employeeNameTextbox. Like many of the posts indicated, this is helpful for grouping. One groups by control types (txtEmployeeName, txtManagerName) while the other can group different related controls together (employeeNameTextbox, employeePhoneTextbox, managerNameTextBox, managerPhoneTextbox). In many cases I find the later more useful while coding.

Answer 2

WPF-specific Answer: No name at all.

Why? Because if you're developing using WPF you should not be naming your controls. If you are, you are doing something wrong.

WinForms required controls to be named because its data binding was so weak. WPF solves all that: The control itself can specify its data and behavior, so there is no need to name it.

Answer 3

I guess it's better to follow Microsoft's Object Naming Convention for naming your controls both in C# as well as Visual Basic.

Answer 4

In VB I actually like to go with [ControlName]_[ControlType]. I can't remember how I started doing that but I suppose it's because it feels like a logical order. It also simplifies coding a bit because the code suggestions are grouped by the control description rather than the control type.

I name controls the same way in C# except I follow C#'s preference for camelCase: [controlName]_[controlType].

I also tend to use my own abbreviations for control types, though they are not vague.

Examples:

VB: Save_Btn and NewFile_MItem (menu item)

C#: save_btn and newFile_mItem

It works for me, but of course every programmer has their style.

Answer 5

Naming your variables is so important. Thick client view conventions seem to be given the short end of the stick. Here are my thoughts:

1. Never put getters and setters for actual business values on your view. Don't do this:

   public Name EmployeeName { get; set; }
   

2. To get or set an EmployeeName, your stateful code should explicitly call a method. Do it this way because it projects that the state is not stored on the view, but can be derived from or transposed to the view:

   public void SetEmployeeName(Name employeeName);
   public Name GetEmployeeName();
   

3. Hungarian notation is stupid. It was useful in languages <= VB6 because they used late binding of variable types. You had to protect yourself because type mismatches were runtime errors, not compile time. Only use txtEmployeeName if you also would use strEmployeeName and intEmployeeNumber.

4. If prefixing the pattern name isn't consistent with your naming convention, don't do it for the control type (which represents a pattern). If you wouldn't create a commandNameFormatting (instead of nameFormattingComamnd), then don't create a textBoxEmployeeName.

5. You'll probably need a suffix of some sort, since EmployeeName doesn't sufficiently describe the variable's purpose. An EmployeeName text box's purpose is to receive input. You could call it EmployeeNameTextBox if that makes you comfortable, but it might be better to call it EmployeNameInput. This has the added bonus that if you have a label, it's clear that EmployeeNamePrompt (or EmployeeNameLabel) is not the same as the text box. Without some sort of descriptive suffix, you don't have a good way to differentiate.

Answer 6

I (almost) always use [controltype][descriptive name]. I want to know right away what type of control I'm dealing with when I look at code, and if I DON'T remember the name, intellisense can help me out.

Just using a descriptive name (EmplyeeName) doesn't work for me. What type of control? Is it a label, a text box, or a combo box? Or a string? Or a file? It's important enough that the type of control or variable is always a part of it.