Hungarian UIs
-
I've never quite understood how strongly some dislike hungarian notation. its just a style :)
-
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.
-
If I have a control that is backing some data object field, let's say UserInfo.FirstName, I'll call it firstName or firstNameEdit, and its label firstNameLabel.
-
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.
Well, I use the full name: TextBoxSomething, LabelSomething.... just because I follow the tendency to use verbose... and it's easier to read. New developers (juniors, just graduated) will always understand that TextBoxSomething is a TextBox and they don't need to know anything about bulgarian... let say txtSomething: a textbox? justa text, like a label, a string? dunno... in other words make your code as readable as possible (for dummies, if you need to have a degree and 6 years experience to read my code... there is something wrong) then being verbose helps a lot. (ok ok, we know that this make your code lines go bigger but then you will also add some other standards...) also, this is just what I like, bulgarian is 1000% better than TextBox x,y,b,a = new TextBox();
-
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 hungarian notation prefix was a memory mnemonic. It disappeared because of things like intellisense, name completion, and go-to-definition shortcuts, which provide the same features without the need for the mnemonic, and work ten times better. Nowdays, I only use it when intellisense, name completion, go-to-declaration are not available in the editor. In UI usage, I use a naming scheme (not hungarian) to provide a clue of which controls are related to each other. The text box that displays a string, and the label on the dialog that indicates to the user what that text box contains, are related. However, unless I'm going to manipualte the label, I don't need a member variable for it and have been known to set GenerateMember to False.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
That's a fair point - I'd not thought of it that way. There's a suggestion somewhere else in this discussion that I quite like which is along the lines of FirstNameInput, thus not implying text box as such.
But if you are serious about UI programming (in WinForms, WebForms, and Mobile Apps) you want to imply a TextBox (WinForms).
Gus Gustafson
-
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 use a naming convention that best suites my programming environment (IDE). When using Visual Studio, with Intelli-sense, I generally will not use any kind of pre or post typing notation as the IDE provides this context with a mouse-over (and you should be able to see its type from its usage in the code). As far as component delineation, as with UI constructs, I favor the noun-verb or noun-noun method of naming; i.e., MyStream_Read, MyStream_Write, MyStream_Flush, etc., or UserName_lbl, UserName_tb, etc. (with or without the underscore, but I do favor caps when not using underscore delimiters). I prefer this method as most IDEs present these entities in sort order. In less automated coding environments (NotePad++) I would use more of the constructs you describe, however, I always maintain sort order naming so its easy to see all labels, functions, or events associated with a given entity or programming construct.
The art of conversation is not only saying the right thing at the right time, but to leave unsaid the wrong thing at a most tempting moment!
-
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 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.
IDEs and OO Programming may be the culprits behind Hungarian notation demise in naming variables, also while naming controls I find that suffixing the type of the control is easier (although more verbose) for me, so I haven't used Hungarian notation in a long while.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
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."
Joe Woodbury wrote:
What does "co" stand for?
"1.Quantities are named by their type possibly followed by a qualifier. A convenient (and legal) punctuation is recommended to separate the type and qualifier part of a name. (In C, we use a capital initial for the qualifier as in rowFirst: row is the type; First is the qualifier.) " "Conversely, the tag for the type of the color value should not be "color."...A typical arbitrary choice could be co" Is that that "co" to which you are referring?
-
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?
Can't say I agree - changing the type of a variable is still very much a difficult job. The IDE will find and replace just fine for internal and private scoped variables, but for anything that's protected or public a change of type could break 3rd party code. This isn't really a problem solved with a good search and replace. Contrast this with swapping a type that maintains backwards compatibility, you'll give 3rd parties far fewer headaches.
-
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)
-
Can't say I agree - changing the type of a variable is still very much a difficult job. The IDE will find and replace just fine for internal and private scoped variables, but for anything that's protected or public a change of type could break 3rd party code. This isn't really a problem solved with a good search and replace. Contrast this with swapping a type that maintains backwards compatibility, you'll give 3rd parties far fewer headaches.
You have to take what I said in context. This is about UI objects. I'd say the majority of developers working with UIs are not working on third party libraries. I also can't think of any good reason to directly use a third party library's UI variable, as anything of this nature is typically scoped (why would you have a public variable for a text box that your library is responsible for when you could keep write acces to yourself and provide read access via a getter in the off chance the party using your library needs it?) I suppose if you're using someone's library of custom UI views you may find issue here, sure, but that's not often done; such code is not likely to change the data type of the variables anyway as they are abstracted to suit the needs of everyone (ex. a third party library that has a pull down to refresh list view for android is not likely to suddenly change the list view to a scroll view.) There are of course exceptions to all generalized statements like the ones I made, but honestly, in context, do you see renaming a UI variable as being an issue? UI objects are typically obfuscated in libraries and within your own code, you can easily rename the variable.
-
You have to take what I said in context. This is about UI objects. I'd say the majority of developers working with UIs are not working on third party libraries. I also can't think of any good reason to directly use a third party library's UI variable, as anything of this nature is typically scoped (why would you have a public variable for a text box that your library is responsible for when you could keep write acces to yourself and provide read access via a getter in the off chance the party using your library needs it?) I suppose if you're using someone's library of custom UI views you may find issue here, sure, but that's not often done; such code is not likely to change the data type of the variables anyway as they are abstracted to suit the needs of everyone (ex. a third party library that has a pull down to refresh list view for android is not likely to suddenly change the list view to a scroll view.) There are of course exceptions to all generalized statements like the ones I made, but honestly, in context, do you see renaming a UI variable as being an issue? UI objects are typically obfuscated in libraries and within your own code, you can easily rename the variable.
99% of the time yes, but I have had to deal with projects which did reference internal UI components, and it was a nightmare to refactor when things needed changing. Admittedly this is an edge case and I agree with you for the most part, but I'm of the opinion that you should be as defensive about these things as possible, even when you don't anticipate problems like this.
-
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.
Just like those few people not afraid of expressing their opinion (against popular dogma) and actually using it for good, I say Hungarian notation is not bad, but good. But just like everything, it is only good when you not overuse it. I'm using it in many cases with some exceptions (when the name actually conveys the type already or when it is a number and I don't really care how many bytes it is or if it signed, etc.). EDIT: Oh, yes, forgot to mention that I'm not using the 'pure Hungarian' prefixes, I just use the principle, making sure the prefixes are unambiguous. What I believe happened, is the Hungarian notation (similar to goto operator) are being witch-hunted, which is triggered by some incompetent and overconfident tongue (or hand/pen, rather) of some wanna-be computer science study book writer (and I'm implying a bunch of quite well-known authors here if you wondered). Well, after that the sheep herd just follows. Please, have your own opinion, people, it is refreshing. Just use the practice you think helps creating clear, maintainable code, regardless of what 'they' say. :)
-
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.
Don't use the system Hungarian. IDEs and compilers see types. If you declare variable like "int X;" in a statically typed language, X is an int. You won't make it float or double by mistake. On the other hand, the application Hungarian notation is still a good practice. In neural network programming, an input-to-hidden weight is double, and so is a hidden-to-output weight. Compilers cannot detect an input-to-hidden variable holding a hidden-to-output weight by mistake. Therefore, anything that has to do with an input-to-hidden weight should be marked with "ih", and anything, with an output-to-hidden, should be marked with "ho". A mistake like "ihWeights[i][j] += alpha * hoPrevWeights[i][j];" cannot be detected by your compiler, but reading just that line, you see your mistake. You should not be adding hoSomething to ihSomething.
-
Just like those few people not afraid of expressing their opinion (against popular dogma) and actually using it for good, I say Hungarian notation is not bad, but good. But just like everything, it is only good when you not overuse it. I'm using it in many cases with some exceptions (when the name actually conveys the type already or when it is a number and I don't really care how many bytes it is or if it signed, etc.). EDIT: Oh, yes, forgot to mention that I'm not using the 'pure Hungarian' prefixes, I just use the principle, making sure the prefixes are unambiguous. What I believe happened, is the Hungarian notation (similar to goto operator) are being witch-hunted, which is triggered by some incompetent and overconfident tongue (or hand/pen, rather) of some wanna-be computer science study book writer (and I'm implying a bunch of quite well-known authors here if you wondered). Well, after that the sheep herd just follows. Please, have your own opinion, people, it is refreshing. Just use the practice you think helps creating clear, maintainable code, regardless of what 'they' say. :)
The silliest part, of course, is the entire subject is subjective; there is no metric for wether Hungarian notation is good or bad. There is no performance difference in prefixing your variables. Each person's ideas of what's more maintainable is different. It's like the curly brace placement debate all over again. XD
-
I have been trying to get away from Hungarian for a loooong time, but I still use txtPassword and butOK and labPasswordPrompt. The original idea of HN was good - and I think it does help to distinguish UI controls with a prefix. If only to make it easier to find in intellisense! :laugh:
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
Yeah, I particularly find it useful... specially when you have lots of fields to fill... Typing txt and seing them all filtered in a neat intellisense list just makes it much easier to manipulate and avoids forgetting one of them.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
I think there's general agreement these days that it's not a good style, particularly if you want to change the underlying type of something without having to do a lot of renaming, aside from the aesthetics of it. However, everybody has seen the arguments for and against ad nauseum but I was curious as to what people do in the UI. One other exception that springs to mind is IInterface, which I don't have any problems with.
There are two types of Hungarian notation. One, the original, which describes purpose and the other which many use, data types. The former has as use because it helps you understand the code and how it is used. The latter, which many people use is a waste of time, unless you are using a typeless language like BCPL, vbscript or javascript.
-
There are two types of Hungarian notation. One, the original, which describes purpose and the other which many use, data types. The former has as use because it helps you understand the code and how it is used. The latter, which many people use is a waste of time, unless you are using a typeless language like BCPL, vbscript or javascript.
