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.
• I find it's easier to look up with Intellisense.
• The convention is similar to the convention used for events (MouseClickEvent, MouseClickEventHandler) and dependency properties (VisiblityProperty).

Note: I am using the full name rather than an abbreviation (such as "tb"), because it is in line with MS's naming conventions that say to avoid using abbreviations.

http://msdn.microsoft.com/en-us/library/ms229045.aspx

Mezcaline

Possible duplicate of Best practices for C# GUI naming conventions? – Defalcation

Answer 1

The only reason to use the control type in the name first (textBoxEmployeeName) is for easier grouping with Intellisense (All textbox controls would then show up together). Beyond that, there really is no benefit to using that way. I find the second way (employeeNameTextBox) more readable and prefer that way personally, but a lot of people will still go with the control type first, since that is the way it was done for a long time.

Confectionary

Answer 2

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.

Wegner

You seem to imply that instead of saying EmployeeNameTextBox you use EmployeeNamePrompt. I think I like this better simply because the way EmployeeName is entered may change in the future and therefore you don't need to refactor. – Aphesis

#1/2 sound like a Java background speaking. In C# (for example), a property is expected to have code that runs when get or set is used--otherwise it would be a field public Name EmployeeName. Forcing people to use SetEmployeeName all over the place will just infuriate them. #3 VB6 (and 5, and 4) don't use late binding, you'd get a compile-time error. Were you thinking of VBScript or perhaps VBA (where compilation and running are near-synonyms)? #4 I can agree with that one! – Jeseniajesh

Answer 3

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.

Icicle

Does it really matter what type of control it is? Can't you just as quickly tell by hovering over the variables, or start to try and use it, to tell what type it is? We have compile time error checking and intellisense for a reason why not use it? – Pyelonephritis

If all I had was Visual Studio, definitely. But I do tend to get some requests in house about why a certain code snippet isn't working and having the prefix comes in handy for debugging these kind of issues without grabbing the front end page as well to verify things. – Retarder

But won't the suffix work just as well as the prefix for this (particular) purpose? – Lewes

But English puts adjectives first. Consider UserName, XmlParser, StreamWriter, NodeFactory. The reverse would be very different things, NameUser, ParserXml, WriterStream, FactoryNode. Putting the control type first violates this .Net near-convention and English customs. – Jeseniajesh

is this pascal case? – Cunctation

Answer 4

I propose a third option: uiEmployeName. Reasons:

1. It's not Hungarian. Both of the notations you mention are just flavors of Hungarian.
2. If you change an employee name text box over to a listbox you don't need to rename your variables.
3. Everything is grouped nicely in the intellisense without involving the type of the object.
4. The name of the object closely follows its function. It is a user-facing object that gets the employee name.

Otherwise

Answer 5

I generally try to keep the element type short, followed by a distinguishing label. I find that it quickly communicates the type and purpose of the element:

txtEmployeeName;
lblEmployeeName;

Armyn

"Hungarian notation" is discouraged in this day and age. See reasons at en.wikipedia.org/wiki/Hungarian_notation – Minimus

Abbreviation is bad for a couple reasons. First, is a TextBox abbreviated as txt or tb, how about checkbox and combobox? Second, what do you do with a custom control called TextDisplayer? Would you call that td, or would you not abbreviate? Consistency is important with naming conventions. – Mezcaline

Dylan, I use abbreviation regularly and experience few if any problems. Certainly if you're working in a large team environment you will need conventions, but I rare if ever have any problems as a result of my naming-convention. TextBox = txt, Checkbox = chk, combobox = cmb, etc. – Armyn

Hungarian notation is only discouraged when it is abused. The problem today is it is abused more than it is properly used. This article might be enlightening: joelonsoftware.com/articles/Wrong.html Calling a TextBox "EmployeeName" is too vague and very missleading, and creates code that is hard to understand when it is just read (perhaps even in paper...there is no guarantee of an IDE.) Effectively using hungarian notation reduces confusion, and if you reduce confusion, its good enough. – Repressive

I for one, used hungarian notation when I didn't knew how to code properly, it looked cool and such. After seeing in practice that it's way too confusing and only serves to group it in intellisense, I consider it a n00b thing, or something inherited by old VB developers. – Ragwort

Answer 6

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

Adrien

Answer 7

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.

Rhodic

What is the point of this answer? 1) it's winforms question 2) sometimes you still have to give names in wpf, e.g. when binding to the view element property. – Stepson

Answer 8

A MUST READ is the XAML Guidelines released by Jaime:

Also read more here

Chari

I strongly disagree with Jaime's suggestion that most logical controls should be named in XAML. If your WPF application refers to more than a tiny handful of controls by name you're doing something seriously wrong. If your XAML files are so big you need named elements to find your place, you should organize them better. Either way, needing to give x:Names to more than a few elements evidences poor coding practices. – Rhodic

Answer 9

As I read it, an article linked to in the article mentioned in the question (namely, Names of Resources) does use the control type at the end, in FileMenu (and ArgumentException though it's not a control).

My personal opinion is that this is also more readable, as it's the employee name text box and hence should be named the employeeNameTextBox, just like the words "File menu" are read in that order. (Though I substitute "Edit" for "TextBox" for brevity — I should probably kick that habit to use control names consistently with the environment name for them.)

Lewes

This is more reasonable, because it front-loads the part that is more unique. Prefix warts are usually a bad idea. – Germanophile

Answer 10

Why not EmployeeName? Seriously how does the control type as part of the name when it is already provided by your IDE assist in delivering easy to maintain code? Consider Ottenger's Rules for Variable and class Naming

K

Liselisetta

how would you name the variable containing the value and how would you name the property to set/get that value? – Writeup

The text box itself is not the employee name. The value it contains is. – Ethelethelbert

@w4g3n3r, still what if you have to do what I just asked? – Writeup

I'd name the variable _employeeName. The text box only carries the input value to the business object that actually holds and persists the value is probably Employee with a Name property. – Liselisetta

I try to avoid naming my controls after business entities or data. Calling a text box "EmployeeName" is very misleading. Hungarian notation still has value in the world of UI components, and I prefer to tag my control names: txtEmployeeName, lblEmployeeName, cboEmployeeName, ddlEmployeeName, btnEmployeeName, etc. – Repressive

Answer 11

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.

Distributary

Answer 12

Ideas:

1. Avoid encodings/abbreviations.

2. The name should stand out from similar names in the same scope. Make the unique-most part the left-most part. I suspect you have several text boxes, but only one is the employee name.

3. Avoid needless context. Are all the names on this page about employees? Is it an "employee" page? Then EmployeeName is redundant. NameBox or NameControl should be plenty.

4. Avoid needless context: do you have names that are not controls? If so, "Box", or "Control" is useful, otherwise not so much.

Disclosure: I am the "ottinger" from "ottingers naming rules", which also evolved to be chapter 2 of "Clean Code". See short form at http://agileinaflash.blogspot.com/2009/02/meaningful-names.html

Germanophile

Answer 13

You should do whatever it is that makes your code readable and self-documenting. Following hard and fast rules is always a mistake because they almost never cover all aspects of what needs to be done. There is nothing wrong with having guidelines (such as not using Hungarian notation), but it is more important that you are consistent and clear with your naming convention, whatever it is, than you follow some rules found on the Internet.

Georganngeorge

Answer 14

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.

Eustache

Answer 15

I don't recommend hungarian notation in any form. textBoxEmployeeName is a form of hungarian notation. So I support the use of employeeNameTextBox.

Personally I don't even bother using the word TextBox, because it is not what is important about the variable. What is important is "Employee" and "Name". Not only does adding the word TextBox lock you in to a certain type, it also make it much harder to change that type, because you need to change the name to normalize your code and make it correct. Say for some reason you started this as a TextBox, but you later received a requirement to change this to a DropDownList or some other type, now you have to update all of your code and JavaScript to make it say DropDownList instead of TextBox.

It is much easier to forget about trying to type your variable names, and just simply name them. You have intellisense and compile time error checking for a reason, why not use it.

Pyelonephritis

The question is not about hungarian or pascal notation. It is about ' Whether we need TextBox(ControlName) in front of the variable name or not. – Reichel

I agree. [type][name] or [name][type] are both forms of Hungarian -- and both basically worthless. – Otherwise

Answer 16

I would go with [controlType][DomainTerm] which in this case is textBoxEmployeeName. The reason is that while coding for the C# code behind you are more care about the UI controls than the domain specific terms.UI(View) side coding we need to identify/recognize the control type faster, which is little more important than the domain specific name in the View side , and since we read from 'Left to right' this naming convention is relevant. I generally use txtEmployeeName or cmpEmployeeType , but textBox instead of txt is preferred as per MS guidelines

Reichel

that is just Hungarian Notation, which people have out right rejected. – Pyelonephritis