Hungarian UIs
-
Strictly speaking strings aren't primitive data types either, but it'd make my skin crawl to name a variable strXyz.
Ha! I wasn't advocating using (and do not use)
strXyz. :-D /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Strictly speaking strings aren't primitive data types either, but it'd make my skin crawl to name a variable strXyz.
-
Giving a variable name passwordString or something comparable is not Hungarian notation. The original intent with Hungarian notation was that a very short prefix would indicate HOW the variable was used, not the actual type of the variable. Thus dX meant delta-X, not that X is an integer. This was quickly perverted into a monstrosity. Name variables with meaningful names is to be encouraged, though in my style most abbreviations are discouraged. In UI programming, I often use Label/Checkbox or some suffix to distinguish controls from data. In C++, I still use Hungarian in three distinct cases: I put a 'p' in front of pointers since the semantics are dramatically different. I put 'h' in front of naked handles for a similar reason--if I see a variable prefixed with an 'h', there better be a CloseHandle or equivalent nearby (code-wise). I also put "m_" in front of class member variables. Oddly I don't do this in C# (except lately since my current peers insist on using the "_" prefix for member variables.)
Joe Woodbury wrote:
Giving a variable name passwordString or something comparable is not Hungarian notation. The original intent with Hungarian notation was that a very short prefix would indicate HOW the variable was used, not the actual type of the variable. Thus dX meant delta-X, not that X is an integer
No. http://en.wikipedia.org/wiki/Hungarian_notation[^] "Simonyi's paper referred to prefixes used to indicate the "type" of information being stored" http://msdn.microsoft.com/en-us/library/aa260976%28v=vs.60%29.aspx[^] "Long, long ago in the early days of DOS, Microsoft's Chief Architect Dr. Charles Simonyi introduced an identifier naming convention that adds a prefix to the identifier name to indicate the functional type of the identifier."
-
Joe Woodbury wrote:
Giving a variable name passwordString or something comparable is not Hungarian notation. The original intent with Hungarian notation was that a very short prefix would indicate HOW the variable was used, not the actual type of the variable. Thus dX meant delta-X, not that X is an integer
No. http://en.wikipedia.org/wiki/Hungarian_notation[^] "Simonyi's paper referred to prefixes used to indicate the "type" of information being stored" http://msdn.microsoft.com/en-us/library/aa260976%28v=vs.60%29.aspx[^] "Long, long ago in the early days of DOS, Microsoft's Chief Architect Dr. Charles Simonyi introduced an identifier naming convention that adds a prefix to the identifier name to indicate the functional type of the identifier."
jschell wrote:
http://msdn.microsoft.com/en-us/library/aa260976%28v=vs.60%29.aspx[^]
"Long, long ago in the early days of DOS, Microsoft's Chief Architect Dr. Charles Simonyi introduced an identifier naming convention that adds a prefix to the identifier name to indicate the functional type of the identifier.""the functional type" Simonyi's paper makes this reasonably clear, though even he allowed some physical types to be represented. I believe the problem is that Simonyi was using "type" when he meant "usage" due, I believe, to English not being his first language. (I found it funny that he writes : "In closing, it is evident that the conventions participated in making the code more correct, easier to write, and easier to read. Naming conventions cannot guarantee good code, however; only the skill of the programmer can." When, for me at least, his example is nearly indecipherable and not clear at all.)
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
-
I can't find it quickly but there was a good article posted here via the news feed (Insider News) that told a story, presumably true, as to what Hungarian was supposed to be for and what it got turned into and that they were vastly different. Anywho the Wikipedia article[^] might help, at least differentiating between System Hungarian and Apps Hungarian. Personally I tend to use the txtAge, lblAge, cmbGender, lblGender, cmdOK, cmdCancel etc. I am intrigued by the idea of switching to AgeTxt, AgeLbl, GenderCmb, GenderLbl, CancelCmd, OKCmd etc., might be better in at least some if not many places. Mike
txtSomething is better than SomethingTxt IMHO, because when I type and want to pull up a control name with IntelliSense I always know the kind of control I will be looking up, but might not remember the actual variable name. So I type txt... and pick the control name from the popped list.
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
Think a big reason that it has disappeared is that display space is not as valuable. There was also the issue of calling something strName, well Name is probably going to be a string anyway, so sort of redundant. In the case of UI there is more TextBoxName vs txtName.
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
Interesting question... When it is up to me, I dabbled fairly recently to using ux as a prefix for all GUI controls - and not naming any controls that don't require a name. So I would have uxCustomerName and uxCustomerNameLabel assuming both were referenced in code somewhere. Makes it obvious which variables belong to the GUI, keeps label and control variables adjacent alphabetically, allows me to change from a text box to a combo without any bother of renaming. But old habits die hard and I still find myself using txtCustomerName!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
c2423 wrote:
lblSomething is clearly meant to be a label which is next to txtSomething
Exactly. What else are ya gonna do? And there's this: Making Wrong Code Look Wrong[^]
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
c2423 wrote:
it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething.
Yes I still use it for controls but not for variables any more.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
jschell wrote:
http://msdn.microsoft.com/en-us/library/aa260976%28v=vs.60%29.aspx[^]
"Long, long ago in the early days of DOS, Microsoft's Chief Architect Dr. Charles Simonyi introduced an identifier naming convention that adds a prefix to the identifier name to indicate the functional type of the identifier.""the functional type" Simonyi's paper makes this reasonably clear, though even he allowed some physical types to be represented. I believe the problem is that Simonyi was using "type" when he meant "usage" due, I believe, to English not being his first language. (I found it funny that he writes : "In closing, it is evident that the conventions participated in making the code more correct, easier to write, and easier to read. Naming conventions cannot guarantee good code, however; only the skill of the programmer can." When, for me at least, his example is nearly indecipherable and not clear at all.)
Joe Woodbury wrote:
Simonyi's paper makes this reasonably clear,
Yes it does. From that paper (Table 4.) "b Byte, not necessarily holding a coded character, more akin to w." Are you suggesting that "b" is used to represent something besides the data type of the variable from the above phrase?
-
Joe Woodbury wrote:
Simonyi's paper makes this reasonably clear,
Yes it does. From that paper (Table 4.) "b Byte, not necessarily holding a coded character, more akin to w." Are you suggesting that "b" is used to represent something besides the data type of the variable from the above phrase?
jschell wrote:
Are you suggesting that "b" is used to represent something besides the data type of the variable from the above phrase?
Read the damn paper. The b is an exception to his use of notation to indicate the usage of a variable. You are deliberately ignoring the other tables which are blindingly clear. Look at table 2 and table 3. Even table 4 save for two damn rows. Then read his whole damn discussion on the color red. What does "co" stand for? Simonyi states: "As suggested above, the concept of "type" in this context is determined by the set of operations that can be applied to a quantity."
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
It seems obvious that these two controls belong together. So it makes sense to group them in a single class "LabeledText", having two fields: "Something.Label" and "Something.Text". With the added benefit that the class can automatically enforce coherence of the two controls.
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
lblUsername, txtUsername That's why. The 'correct' solution is presented by WPF (and HTML): you don't *need* to name controls. However, when I am doing Winforms: usernameTextBox, usernameLabel. No idea why, it's just style preference (or possibly hungarian aversion).
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
It seems obvious that these two controls belong together. So it makes sense to group them in a single class "LabeledText", having two fields: "Something.Label" and "Something.Text". With the added benefit that the class can automatically enforce coherence of the two controls.
YvesDaoust wrote:
With the added benefit that the class can automatically enforce coherence of the two controls.
Some older libraries actually did do it this way. One that jumps to mind is Delphi's Borland Foundation Classes. But then you also ended up with other issues, e.g. say you wanted the label above the control? Do you need to make a new container class for that? Or do you need to extend the base container so it had a prop to state left/top/right/bottom -label. Or do you make like BFC did by having a 2nd location point for the label so it could freely be moved about on the GUI-Designer yet still snap to the "default" positions. But worse: if you want to align controls, you want it to ignore the label and align "controls", so your class needs to account for that too. And then what about stuff like font / colour / enabled / read-only / etc. are you going to expose all possibilities through pass-through properties, or rather just pass the child controls as public (i.e. breaking general OOP principles)? So your container class is not going to be a trivial thing at all, at least not for something you want to use extensively in various situations. IMO, if your current library doesn't provide such combined control+label classes, you're wasting your time making them simply to avoid prefixing / suffixing their variables. If you've got other reasons for doing so, then those are why you'd want to make such combined control. I do like the idea of a suffix for sorting purposes yes, but also I like the idea of intellisence / auto-complete picking up txt as well. So I'm a bit in 2 minds as to which one to use in preference. Though I do try to steer clear of tieing the name to some aspect of the control (e.g. I don't use txt for Text / cmb for Combo Box / tgl for Toggle / etc. etc. etc.) that just makes life more difficult on any change. I generally use lbl for labels and fld for inputs (i.e. "Field" like in a db form) even drop-downs/toggles.
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
The name of a variable should indicate what it's used for, so I see no reason not to use Hungarian notation as a means to distinguish between different kinds of UI components. Since there is only a limited number of different components, it makes sense to abbreviate them rather than using the full name.
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
Hungarian notation is an abomination before God :suss:. Besides, everyone knows that the proper naming convention is
_Something__label,_Something__value, etc. :-DSoftware Zen:
delete this; -
lblUsername, txtUsername That's why. The 'correct' solution is presented by WPF (and HTML): you don't *need* to name controls. However, when I am doing Winforms: usernameTextBox, usernameLabel. No idea why, it's just style preference (or possibly hungarian aversion).
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
I guess I'm going to have to disagree with everyone here. What happened to verbosity being a good thing in software development? Prefixing variables referencing UI objects makes your code more self documenting. I know that txtFirstName is an editable text box and firstName is most likely just a string. If you remove ui prefixes, all bets are off. You no longer have any indication as to what a variable's type/implementation is without either scrolling up to its declaration or hovering over the variable in a compatible IDE. The argument that changing the type of the variable is difficult is largely not the case anymore. The modern IDE has *at least* find and replace, and most have a right click -> Refactor -> Rename option. Should we really sacrifice self documentation for the off chance that a text box reference will be changed to a label?
-
I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.
In general, a reason NOT to use Hungarian Notation is that it keeps the programmer from abstracting the data from the type. In fact, it does the opposite. For UI controls, the variables are NOT abstract from the control; they are intrinsically linked. They are one in the same. There's nothing to make more abstract from a variable "okButton." A button is a button, but an Uint16 could be just about anything. So, I say using the Hungarian-like notation for specific control types makes sense.