Do you name controls on forms using the same convention as a private variable?

Question

For some reason I never see this done. Is there a reason why not? For instance I like _blah for private variables, and at least in Windows Forms controls are by default private member variables, but I can't remember ever seeing them named that way. In the case that I am creating/storing control objects in local variables within a member function, it is especially useful to have some visual distinction.

Answer 1

This might be counter-intuitive for some, but we use the dreaded Hungarian notation for UI elements.

The logic is simple: for any given data object you may have two or more controls associated with it. For example, you have a control that indicates a birth date on a text box, you will have:

• the text box
• a label indicating that the text box is for birth dates
• a calendar control that will allow you to select a date

For that, I would have lblBirthDate for the label, txtBirthDate for the text box, and calBirthDate for the calendar control.

I am interested in hearing how others do this, however. :)

Answer 2

Hungarian notation or not, I'm more curious if people prepend m_ or _ or whatever they use for standard private member variables.

Answer 3

I personally prefix private objects with _

Form controls are always prefixed with the type, the only reason I do this is because of intellisense. With large forms it becomes easier to "get a labels value" by just typing lbl and selecting it from the list ^_^ It also follows the logic stated by Jon Limjap.

Although this does go again Microsofts .NET Coding Guidelines, check them out here.

Answer 4

For me, the big win with the naming convention of prepending an underscore to private members has to do with Intellisense. Since underscore precedes any letter in the alphabet, when I do a ctrl-space to bring up Intellisense, there are all of my _privateMembers, right at the top.

Controls, though, are a different story, as far as naming goes. I think that scope is assumed, and prepending a few letters to indicate type (txtMyGroovyTextbox, for example) makes more sense for the same reason; controls are grouped in Intellisense by type.

But at work, it's VB all the way, and we do mPrivateMember. I think the m might stand for module.

Answer 5

I came through VB and have held onto the control type prefix for controls. My private members use lower-camel case (firstLetterLowercase) while public members use Pascal/upper-camel case (FirstLetterUppercase).

If there are too many identifiers/members/locals to have a 90% chance of remembering/guessing what it is called, more abstraction is probably necessary.

I have never been convinced that a storage type prefix is useful and/or necessary. I do, however, make a strong habit of following the style of whatever code I am using.

Answer 6

I don't, but I appreciate your logic. I guess the reason most people don't is that underscores would look kind of ugly in the Properties window at design time. It'd also take up an extra character of horizontal space, which is at a premium in a docked window like that.

Answer 7

Hungarian notation or not, I'm more curious if people prepend m_ or _ or whatever they use for standard private member variables.

Luke,

I use _ prefix for my class library objects. I use Hungarian notation exclusively for the UI, for the reason I stated.

Answer 8

I never use underscores in my variable names. I've found that anything besides alpha (sometimes alphanumeric) characters is excessive unless demanded by the language.

Answer 9

I'm in the Uppercase/Lowercase camp ("title" is private, "Title" is public), mixed with the "hungarian" notation for UI Components (tbTextbox, lblLabel etc.), and I am happy that we do not have Visual Case-Insensitive-Basic developers in the team :-)

I don't like the underscore because it looks kinda ugly, but I have to admit it has an advantage (or a disadvantage, depending on your point): In the debugger, all the private Variables will be on top due to the _ being on top of the alphabet. But then again, I prefer my private/public pair to be together, because that allows for easier debugging of getter/setter logic as you see the private and public property next to each other,

Answer 10

I write down the name of the database column they represent.

Answer 11

I use m_ for member variables, but I'm increasingly becoming tempted to just using lowerCamelCase like I do for method parameters and local variables. Public stuff is in UpperCamelCase.

This seems to be more or less accepted convention across the .NET community.