Naming convention for controls

views:

1430

answers:

+10 Q:

Naming convention for controls

Microsoft has naming guidelines on their website (here). Also I have the Framework Design Guidelines book.

What I could not find was a guideline about naming controls.

For example a button, when dropped to a form, it gets the typename + number, camel-cased as default name, such as "button1".

This is what I do: I delete the number and add a meaningful description after. For example "buttonDelete" or "buttonSave".

This way you do not have to maintain a big list of controls and their abbreviated names in a guideline somewhere.

Do you agree ?

yes - I agree totally (but I rename it to ButtonDelete) so lowercase names are for variables in my case :)

personally I think as long as you are consistent you won't run into problems even if someone else is reading your code.

Gambrinus 2009-03-13 13:44:55

I wouldn't rename to ButtonDelete because every control you drop on a form becomes a private instance member of the Form class. Private instance fields are camel cased by default.

Patrick Peters 2009-03-13 13:54:28

okay - as I said as long as you are consistent with your definitions and they are not way out of line - I think you are okay :)

Gambrinus 2009-03-13 13:59:56

+1 A:

I'm not sure, but I think that control naming in winforms is one of the only places I can see a use for Hungarian Notation. So I think you're good.

Jason Punyon 2009-03-13 13:45:25

+1 A:

Yes, you need meaningful identifiers for any variable - control or not - the default names are only because your IDE knows nothing about your problem domain and so can't always 'guess' a better name.

Mark Pim 2009-03-13 13:45:59

+3 A:

Yes channge those names

For me:

Button btnDescription

TextBox txtDescription

ComboBox cboDescription

ect..

2009-03-13 13:46:34

+1 because I use this too. However, I'd really like someone to tell me it's out-of-style and there's a better way. Hungarian is soooo icky.

Jon B 2009-03-13 13:48:21

I _hate_ this style. This is the worst form of hungarian notation and it hurts my eyes. I'd stick a pencil in an eye of a developer in my team who would want to do this.

Krzysztof Koźmic 2009-03-13 13:51:20

Hungarian is only really icky, IMHO, when taken to the Windows API extreme - e.g. lpstrzOut where the type annotation takes up more space than the name itself! Joel, as usual, has it right http://www.joelonsoftware.com/articles/Wrong.html

Mark Pim 2009-03-13 13:52:05

How do you enforce this with a team of 100 developers for example? Well...you have to write it down in a guideline. And then... you have to maintain it for every new control (toolkit) developers will use...

Patrick Peters 2009-03-13 13:58:45

@Patrick - that's a good point. You can have dozens or even hundreds of control types. Having a 2-4 letter prefix for each one is absurd. I usually generalize (an IP address input is just txt, for example). However, the whole concept may be obsolete anyhow.

Jon B 2009-03-13 14:08:24

+1. I don't use it anywhere else but here. When you're working with the code you want a button but you wont know the names of all the buttons you just say want the one on the top right, whatever the hell it is called. This + intellisense makes it easy to discover the name o it.

Quibblesome 2009-03-13 14:48:03

+1 I'm with Quarrelsome; just use this notation for controls to make it quicker to find stuff. Plus I work with web apps so I have far less controls to worry about.

Nick 2009-03-13 15:01:03

I believe that current thinking frowns upon including the control type in the name. I'd be inclined to treat them as another other object I'm using and follow the same naming convention.

Certainly use meaningful naming, that goes without saying :) However, at the end of the day, if your naming convention still makes sense to you when you revisit your code months later then I'd probably stick with it.

Lazarus 2009-03-13 13:48:57

+2 A:

I don't do WinForms for quite some time but what I did was two things.

uncheck 'generate member' (or however it is called) for things like labels, etc. Basically ensuring I keep as fields only things I need.
for those I need, set descriptive name. It if is necessary, append the name of the control (ie saveButton). If I don't feel like adding a control name adds any value I would not append the 'Button' and leave the name simply as 'save'.

Basically most of the time I would not create a member for save button at all. (If you have some save logic you still can have only OnSaving event handler subscribed to the button's Click event).

Krzysztof Koźmic 2009-03-13 13:49:11

+1 for "uncheck generate member" approach

ee 2009-03-13 15:07:59

+6 A:

I don't have a convention as such, but I do try to be very broad with the 'type' portion of the name. e.g. Button, Link Button, Image Button tend to be named 'somethingButton'. Combo boxes, radio button lists all end up as 'somethingSelector'. TextBoxes and Calendars are 'somethingInput'. That way I get a rough idea of what sort of control it is without the name being tied to the actual implementation. If I decide to replace an option button group with a dropdown then no need to rename!

Jon M 2009-03-13 13:53:25

That's a really good idea. The most important thing is that the name reflects what the control is for. +1

Mark Pim 2009-03-13 13:54:56

That's exactly my point as well, you just expressed it better. +1

Krzysztof Koźmic 2009-03-13 13:57:05

I like the "implementation independent" name idea in theory, but in practice I find the refactoring of a control name to be near-instantaneous. Thus its a tradeoff between the time taken to "fix" the name when creating vs possibly refactoring it later. In the IDE, the latter is pretty fast.

ee 2009-03-13 15:15:29

@ee - I agree that renaming is painless in VS, but chances are it'll get forgotten when time is tight and soon the 'LinkButton' controls will point to 'ImageButton's etc etc...

Jon M 2009-03-13 15:26:13

+1 A:

GUI programming gets the short stick when it comes to conventions of all sorts. See my answer to another question for the guidelines I use for naming.

Michael Meadows 2009-03-13 13:59:04

I'm probably one of the last few people that still uses Hungarian notation. I know that argument that the IDE can tell you the variable type, but that doesn't help me when I'm coding in Notepad++ or looking at a printout.... anyway, I use the "btnSave", "cbOptions", "txtFirstName", "lblTitle", "ddlCardType", etc... I just like being able to glance at code and know what I'm looking at without looking for a declaration or hovering over a variable to get it's data type from the IDE.

mlindegarde 2009-03-13 14:40:01

This is what we are using

In short, we prefix the controls with an abbreviation of the control. ie

Buttons = btnDelete, btnSubmit, btnReturn

Textboxes = txtUsername, txtPassword etc

that way, by typing the abbreviation you get all the similar controls by the time you finish typing the abbreviation ie type btn and intellisense will list all the buttons you have added so far.

Konstantinos 2009-03-13 14:46:34

+5 A:

ee 2009-03-13 15:00:29

The length of the variable is relevant when you are regarding the performance in ASP.NET. The variable names could be part of the html-downstream.

Patrick Peters 2009-05-18 05:51:44

@Patrick Peters - Good point. From the samples, I felt like this was mostly a discussion of WinForms controls wherein the name length would have minimal impact. However, I agree that, in the larger discussion including ASP.NET it would be different. I will update and explicitly state this assumption.

ee 2009-05-18 16:34:57

+3 A:

Here are some common ones:

frm Form
mnu Form menu
cmd Command button
chk Check button
opt Radio button
lbl Text label
txt Text edit box
pb  Picture box
pic Picture
lst List box
cbo Combo box
tmr Timer

NoahD 2009-03-13 17:04:00

ansaurus

tags:

views:

answers:

Naming convention for controls

related questions