Naming control member variables

Onion Blog

Syndication

As I've been broadcasting a series of webcasts for MSDN, a number of people have asked me about the naming conventions I use for variable names in my code. There's nothing like coding live in front of 1000 people to make you self-conscious about your coding style :) For the most part, I have adopted the recommended standards set by Microsoft (and the .NET programming community at large). This means camel case for member variables, pascal case for type names, and so on.
However, when I'm writing ASP.NET or WinForms code, I often find it useful to name control member variables with the type of control (sort of an inverted Hungarian notation). For example, if I had a textbox on a form for a person's name, I would create a corresponding variable in my form class:
 
TextBox nameTextBox;
 
I find this useful because I then know that the variable is a control and I know what type of control it is. I haven't found any documented conventions along these lines, and I was wondering if anyone else follows this (or a similar) convention when naming control variables? If so, please post a comment here and let me know.

Posted Dec 29 2004, 03:02 PM by fritz-onion
Filed under:

Comments

dominick wrote re: Naming control member variables
on 12-29-2004 1:18 PM
hi fritz,

i would name the variable

TextBox txtName;

i also use lst for listboxes, btn for Buttons a.s.o.

The advantage (at least for me) is that when alphabetically sorted (e.g. in IntelliSense) all the control types are grouped together.

dominick
dominick wrote re: Naming control member variables
on 12-29-2004 1:20 PM
aah - one addition - but i don't use variable names like

string strName or
int intAge

i don't like that....maybe a little inconsistency....:)

dominick
Jose Lema wrote re: Naming control member variables
on 12-29-2004 1:26 PM
I have followed the same convention for the past year. One benefit is when I've got a couple of controls for a single logical data point, I don't have to make up meaningless names (ie. both nameLabel and nameTextBox can live inside of namePanel).
One of the downsides occurs when option lists grow to a size that cause RadioButtonLists to morph into DropDownLists for usability. That said, I often use ListControl on my codebehind page in order to remove that dependence (unless using the RepeatColumns/Direction/Layout).
Phil wrote re: Naming control member variables
on 12-29-2004 1:56 PM
That's a good practice and one I follow.
Sean Chase wrote re: Naming control member variables
on 12-29-2004 2:54 PM
Interesting post. This might sound like overkill, but what I do is follow the MSDN standards for everything except control IDs. It is the reverse of what you do. I would do

TextBox textBoxName;

The reason being: auto-list members. That way if I have a bunch of textboxes, they are all very easy to find.

textBoxAddress
textBoxName
textBoxPhone

I do that for every type of control. I'd rather deal with the long names for the convenience. The long names are not an issue for me for several reasons. 1) the default name "TextBox1" is easy to change to "textBoxName" for example, 2) CTRL+SPACE is second nature to me for auto-list members, so I rarely type in anything in full, 3) VS.NET 2005 brings up auto-list members for you a lot more than VS.NET 2003, 4) it is a very readable naming convention.
Sean Chase wrote re: Naming control member variables
on 12-29-2004 2:58 PM
Also, one other reason is standardization on a team. If I were to use "txtName" instead of "textBoxName", everyone ends up using their own version of "hungarian notation" for lesser-used controls. If you prefix with: textBox, dataGrid, repeater, etc, etc...there is no question as to what type of control you are dealing with. This is a standardization battle I fought a couple of contract gigs ago. :-)
Fritz Onion wrote re: Naming control member variables
on 12-29-2004 3:00 PM
I can see the rationale behind prefixing the name with the type (Dominick & Sean), but I guess I like the way it flows with the name first and the type second - almost like you'd use it in a sentence:
In the nameTextBox, type the value...
Shannon J Hager wrote re: Naming control member variables
on 12-29-2004 5:13 PM
I use "NameTextBox" because it reads like I think it. I have learned that any attempts at being clever on my part almost always end up causing more work or at least causing more confusion and taking more time to remember what clever method I was using.
To me "txtName" is just too clever to remember, too hard to read aloud, and puts the emphasis on the wrong thing (the control type instead of the purpose). Changing "NameTextBox" to "NameDropDownList" seems easier to me because I am still looking for the Name, the type of control is secondary.
Also, when I look for the Name TextBox, seeing it written like that makes the most sense to me and I don't have to remember rules because it is written exactly how I think and say it.
Jason Bunting wrote re: Naming control member variables
on 12-29-2004 8:13 PM
Ditto on nameTextBox style - My rationale for not using textBoxName or TextBoxName, etc. so that they all show up together in intellisense is that when I am writing code, I don't use the organization of that list as the basis for my code - if I were setting a property of an entity, say a Student entity, I would do it thus:

student.FirstName = firstNameTextBox.Text;

Since it is the FirstName I am trying to set, that is what I would start typing on the right side of the assignment operator . . .
Ivan wrote re: Naming control member variables
on 12-29-2004 11:07 PM
That's what I do. It follows the recommended naming for properties:

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconPropertyNamingGuidelines.asp
Craig wrote re: Naming control member variables
on 12-30-2004 6:43 AM
I'm with Dominick and Sean: prefix not suffix.
GuyIncognito wrote re: Naming control member variables
on 12-30-2004 9:03 AM
I use the suffixes listed below for controls. I follow the Microsoft guidelines for all other code. I'm not a huge fan of attaching 'TextBox', 'Label' and the like... but can't think of a better alternative.

Label shippingAddressLabel
TextBox billingLastNameTextBox
Button,
LinkButton,
ImageButton placeOrderButton
HyperLink viewProductDetailLink
DropDownList,
ListBoxDataList creditCardTypeList
Checkbox giftWrappingCheckBox
RadioButton expressShippingOption
DataGrid shoppingBasketGrid

I'm curious as to what you use in your normal code blocks?

DataSet ordersDataSet = ...;

or

DataSet orders = ...;

I prefer the second option personally. I like to keep my lines of code to around 80 characters. If I must, I'll start a new line and ident but that tends to get messy.

I guess I shouldn't worry so much about how pretty the code is... :)
Jason Langston wrote re: Naming control member variables
on 12-30-2004 10:30 AM
I'm with the suffix crowd, for the same rationale as Jason Bunting.

And like Fritz this is only for UI widgets, I never have ordersDataSet, unless my code is specifically concerned with the fact that it is a DataSet rather than what the DataSet represents.
Mark A. Richman wrote re: Naming control member variables
on 12-31-2004 7:09 AM
I like to use the following convention:

DataSet dsOrders = ...;
DataAdapter daFoo = ...;
SqlConnection con = ...;
TextBox txtLastName = ...;
DropDownList ddlState = ...;
ComboBox cboItems = ...;

With intrinsic types, I do not use hungarian:

string foo;
int bar;
double baz;

What does everyone use to denote member variables? I prefix mine with an underscore...I guess this is a holdover from my MFC days when I did stuff like 'm_strFoo':

public class Foo
{
private string _bar = string.Empty;
}

Kevin Daly wrote re: Naming control member variables
on 12-31-2004 10:15 PM
I've been doing something very similar with the control variables, although so far I hesitate between putting the TextBox bit first (and camel casing) or last (although last is probably more logical and less Hungarianish).
Some explicit guidance from MS might not be a bad idea (although they would have to get their own act together first: surely I'm not the only person dismayed by the fact that the VS.NET-generated control variable names for ASP.NET are apparently inconsistent with their own naming standards and with Windows Forms...and for God's sake, somebody tell book authors and contributors to MSDN magazine that it's *way* past time to wean themselves off Hungarian notation)
Mark A. Richman wrote re: Naming control member variables
on 01-01-2005 5:35 AM
Agreed. With strongly typed languages such as C# and IntelliSense™, we don't need Hungarian notation littering our code.

I've found Juval Löwy's IDesign C# Coding Standard useful as well: http://www.idesign.net/idesign/download/IDesign%20CSharp%20Coding%20Standard.zip
Sean Chase wrote re: Naming control member variables
on 01-03-2005 12:44 PM
Fritz - What you are saying is totally reasonable. The type name first gives me an easier-to-read list of controls of type "x" in the auto-complete list in Visual Studio, which I personally find to be very convenient. Especially if the entire team is using that standard, it makes maintenance programming much nicer. :)
Ben Taylor wrote Underscores anyone?
on 01-07-2005 7:46 AM
So does anyone use _ as prefix of member variables anymore? The reason I ask is that I used FxCop on my code the other day and it has a field day on the ASP.NET controls named _myControl, but I still think it helps.
Mark A. Richman wrote re: Naming control member variables
on 01-10-2005 10:57 AM
Kevin Wood wrote re: Naming control member variables
on 02-01-2005 3:45 PM
Our company has adopted putting the control type after the logical portion of the name for the original reasons that you cite. Additionally, non-visual fields get the _ in front of them.
Keith Hill wrote re: Naming control member variables
on 02-12-2005 9:12 PM
I do the same thing with control variable name names: addressTextBox, submitButton, etc. Other than controls though I don't use any other hungarian notation.
Ade wrote re: Naming control member variables
on 03-14-2005 3:14 AM
There is a bit of a contradiction in the naming standards regarding underscores. One of the rules says dont use underscores and the other says members/ variables should not differ by case alone. So if you have a class level varaible named person and u would like to create a Property named Person. You are going against the rules. Also if you then put an underscore in front of class level variable person like this _person, you are breaking the rules also. You will find that a lot of developers tend to ignore the _ rule to get around this contradiction. So its very common to see people having class level variables as _person and then Properties defined in the class as Person.
,l wrote re: Naming control member variables
on 03-29-2005 12:04 AM
l
Carl wrote re: Naming control member variables
on 05-28-2005 11:32 PM
I'm with you man, prefixing the controls name with the controls type is the way to go. Some people say use txt, lbl, lst, etc, for IntelliSense, but if you do that you get a list of all the txt's and lbl's, instead do it your way, then you get all the related controls grouped together, so it's just better.


Coding is NOT a CRIME...
Patrice wrote re: Naming control member variables
on 06-20-2006 7:57 AM
I've used all three control naming conventions:
- txtFirstName
- textboxFirstName
- firstNameTextbox

The easiest to use (when moving from one project to another) has been controlName: textboxFirstName.

The reason is very simple, in many cases, there's many ways to name a property: Is it Birthdate or DateOfBirth, is it FirstName or GivenName, is it CompanyName or Name?

By using the control prefix and intellisence, you don't have to switch to the UI to "remember" what it is.
Oskar wrote re: Naming control member variables
on 01-17-2007 7:30 AM
I use nameTextBox, and I think that the argument that using txtName combined with IntelliSense to get a list of all text boxes is quite weak. Why? Because "name" should not be chosen arbitrarily but have a connection to the content of the text box. If I have a text box containing a birth date it should be named birthDateTextBox. This works 99% of the time for me, meaning that I don't have to switch to the visual editor to get the control name.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?