views:

184

answers:

7

Over the past several years I have been using the naming convention of FirstNameTxt when I'm referring to a TextBox Control for a 'First Name' field. However, I've noticed the majority of other developers tend to use the naming convention txtFirstName

Which is the best convention to use?

+18  A: 

I like using the Hungarian Notation - prepending with a 3-letter abbrev - if for any other reason, all the textbox controls are grouped together in the list of controls for the page.

DShultz
+1 Exactly why I do it
Josh Stodola
+1 from me for the same reason, though I sometimes feel a bit inconsistent since controls are the *only* thing that I use Hungarian notation on.
Adam Robinson
+1 - Our standard within our development group is Hungarian Case for all controls to group them (with a document indicating the abbreviation per control)
Joel Etherton
@Adam Robinson - My development team created a standard for all of our development, and we use Pascal Case, Camel Case and Hungarian Case to separate out the usage of any entity. Hungarian was used chosen only for controls on forms as well.
Joel Etherton
3 letter object + Camel Cased Identifier (txtFirstName) is the best way to keep track of your objects. Also helps limit your intellisense context menu if you type txtFirst instead of scrolling through FirstNameLbl, FirstNamePnl, FirstNameTxt. If you type FirstName and Do Ctrl+Space, you would have 3 listed instead of it just filling in with txtFirst...
Josaph
Is think it would be wiser to follow Microsoft's own naming recommendations which discourage from using hungarian notation. If all did so, nobody would have to change his habits when moving to another project/team.
František Žiačik
A: 

One isn't better than the other. The most important thing is to be consistent in whichever convention you choose.

Since you have been using your current convention for the past several years, I wouldn't change because then you will have broken convention. Unless, of course, you choose to go back and refactor all of your existing code for the new convention. But that begs the question "why bother?".

Darvis Lombardo
I would disagree. One provides a benefit (grouping controls of the same type in Intellisense), the other provides you with nothing. Convention is not an absolute justification for itself.
Adam Robinson
@Adam: I would disagree with you though. The other provides you with better readbility, the first one provides you with nothing with the new intellisense.
František Žiačik
The "other" (the second) provides nothing. It's not necessary to attach the type to the name in order to identify the type of the variable. Why do you say that the first approach provides nothing with the new intellisense?
Adam Robinson
@Adam: about the intellisense - explained in my answer.
František Žiačik
@Adam - good point on the intellisense grouping especially when editing another developer's code. I know that I'll name a comment field CommentText, but that doesn't mean the other guy isn't going to name it UserCommentText or something like that. Having everything grouped in intellisense would make it easier to find what I'm looking for in this case.
Darvis Lombardo
@Darvis: what's the difference - still one can have named it txtComment, another one uxComment or textComment or editComment.
František Žiačik
True, but I was assuming the other developer would have been following the "txt" prefix convention which would have grouped all text boxes in intellisense.
Darvis Lombardo
A: 

From the research I did on the same subject there seems to be no true consensus or best practice. People will argue that it should be txtFirstName, FirstName, and FirstNameTxt. My suggestions is that as long as its consistent then you are fine. Nothing is worse than coding when the names switch around.

As an aside I use txtFirstName.

bechbd
+1. Both `txtFirstName` and `FirstName` (though I'd argue `firstName`, since it's an instance variable, not a public member) make sense, but `FirstNameTxt` makes none to me; type information is already available, why put it in the name if it isn't going to aid in sorting?
Adam Robinson
@Adam: It's because it's a "FirstName Textbox", not "FirstName" itself. You could have another property called `FirstName` of type string that would do exactly what it is named.
František Žiačik
@František: It shouldn't be named `FirstName` at all, as instance variables (if we're talking about the MS-recommended conventions) should be camel-cased, not pascal-cased.
Adam Robinson
@Adam: yes, of course, but that's not the point.
František Žiačik
A: 

The .NET Framework guidelines recommends that the first character is lower case. Like "txtFirstName" or "awesomeVariable" etc.

http://msdn.microsoft.com/en-us/library/x2dbyw72(v=VS.71).aspx

See this list of recommendations. :)

Einarsson
+1  A: 

Since Visual Studio 2010, there is absolutely no reason to use Hungarian Notation.

The only reason one could imagine - to easily search for similar controls with intellisense, goes away with new intellisense which searches in full text.

Thus typing Text in code editor finds you all: firstNameText, lastNameText, anyText.

And it's much easier to read "firstNameText" than "txtFirstName" in code.

František Žiačik
Truly I don't see how appending Text to the end of word is less Hungarian notation than appending it to beginning of the word.
Sergej Andrejev
@Sergej: it's because the Text (or rather TextBox) at the end has nothing to do with the type of property - it is a human readable naming of a thing: first name textbox.
František Žiačik
@MarkJ: did you really read my answer?
František Žiačik
@Frantisek, I thought I had, but obviously not very carefully. Sorry I will delete the offending comment now.
MarkJ
It depends what evil do you see in Hungarian notation: unreadable shortenings or repeating variable type. To me it's the second therefore I rate appending suffix to the end of variable on the same level as appending prefix to the beginning.
Sergej Andrejev
It's not about shortenings, it's about having code look like txtThis, txtThat, making all the variables look similar. Appending to the end makes it more readable because it is more like human language. And all these comments stating that prependig prefixes is better because it is better with intellisense, are now simply not true. I will always strongly discourage my team from any prefixes.
František Žiačik
I think i might stick with 'FirstNameTxt'. As František states, its more readable, plus it means I can group controls of a certain section together, rather than type. Ie. 'RegisterFirstNameTxt' and 'RegisterCountryDdl' will stay seperate from 'LoginUsernameTxt' and 'LoginRememberMeChk'.I've just always been curious as to why 'txtFirstName' is more popular with developers, but if there is no obvious reason I may as well keep the current convention!
Curt
A: 

I generally use "ux" for "User eXperience" as a prefix for control names. This makes it easier to switch control types while maintaining the same name. Since controls have a shared inheritance hierarchy, it's often possible to switch from one to another, for example from a label to a textbox without changing the prefix from "lbl" to "txt". It also groups all controls together in the list so I don't have to remember the type of control I'm looking for.

Jamie Ide
I use "ForenameTextbox" for controls, because I hate hungarian notation the noise it adds, but "ux" is a new one - i like that
Matt Roberts
You never have two controls of different types that display the same information? For instance, depending on user security, you show a FirstName textbox or a FirstName label?
Jason Berkan
Not often on the same form/control. I almost always do separate forms or user controls for read-only/editable views. When it does happens I typically add a suffix, i.e. uxFirstNameLabel.
Jamie Ide
A: 

I don't use Hungarian notation. If I have trouble remembering the exact names of controls on my form, then I'm doing something wrong. Most likely the form class is doing too much and has several responsibilities.

To fix that I usually split the form into subsections using user controls and cleanly separate concerns across them. As an added bonus the code gets easier to test.

Hristo Deshev