 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / February 2008Worse than Hungarian notation?
I'm an old Hungarian (e.g. "clsSystem") fan that came reluctantly to the other side. I was told how it was no longer needed since one could just mouse over a term to see the type. However, for various reasons, everywhere in our new project the type is appended to the object name (e.g. "SystemClass"). I definitely think something is needed because so many of our words are reserved keywords anyway, but doesn't this make the argument against Hungarian moot? I do understand that Hungarian requires all developers to know the 3-char prefix for every type, but the trade-off is all that wordiness when the type is put as a suffix. Thanks for any feedback, Ron > I'm an old Hungarian (e.g. "clsSystem") fan that came reluctantly to the > other side. > > I was told how it was no longer needed since one could just mouse over a > term to see the type. That's not the argument I (or all the other anti-Hungarians of the first hour) would have used against it, but whatever works for modern times. > However, for various reasons, everywhere in our new project the type is > appended to the object name (e.g. "SystemClass"). Ah, reverse Hungarian. :-) Tell your colleagues to stop that nonsense. A class should not end in "Class", unless it actually *describes* a class (i.e. is a metaclass), and I don't think you'll see many of those in your projects, since .NET already has Type and the like. > I definitely think something is needed because so many of our words are > reserved keywords anyway, Then prepend them with @. That's what it's there for. In my code, I often have to use variables named "operator", but, of course, that's also a keyword. Rather than contrive some roundabout name that wouldn't be half as clear (because "operator" is just the accepted term in the world I'm modeling), I can just use "@operator" instead. That said, if you have a class named "SystemClass" because you don't want to name it "System", then the question becomes: why the hell would you have a class named "System"? That's the worst name for a class I can think of. It's about as descriptive and evocative as a brown paper bag. At the very least it should be some *kind* of system, but even then... Do you have ObjectClass, by any chance? :-)  SignatureJ. Thanks for the info. I was thinking of "System" as a good example because in the cable industry a "system" is a cable system. I know what you'll say... "CableSystem" but that's more typing :) Thanks >> I'm an old Hungarian (e.g. "clsSystem") fan that came reluctantly to the >> other side. [quoted text clipped - 29 lines] > > Do you have ObjectClass, by any chance? :-) > Thanks for the info. I was thinking of "System" as a good example because > in the cable industry a "system" is a cable system. I know what you'll > say... "CableSystem" but that's more typing :) CableSystem would be wrong imo because presumably it would be in the Cable namespace. If all children objects prepend their parent's name we'd end up with very long object names. :-) I see this in databases all the time with fields like CustomerFirstName, CustomerLastName etc. Michael >> Thanks for the info. I was thinking of "System" as a good example because >> in the cable industry a "system" is a cable system. I know what you'll [quoted text clipped - 4 lines] > with very long object names. :-) I see this in databases all the time with > fields like CustomerFirstName, CustomerLastName etc. I have to wonder why typing five extra characters is considered any kind of problem. It is not any kind of argument against meaningful names that I can imagine. Long names aren't bad either. Consider that a successful program will spend MUCH more of its life being maintained than developed. Self-documenting names are much more important to maintainers than saving a few nano-ergs of typing energy can be to the developer, especially with IDEs that provide all sorts of shortcuts to inserting long names. Names need to be meaningful in the problem domain and to make maintenance easier. Do not use negligent laziness as an engineering principle. SignatureLew > [...] > I have to wonder why typing five extra characters is considered any kind > of problem. It is not any kind of argument against meaningful names > that I can imagine. > > Long names aren't bad either. Let me emphasize that I agree completely with this. Some people seem to be under the impression that Hungarian is about shortening variable names. It's not. It's about (among other things) providing useful semantic information in identifiers that isn't necessarily represented solely in the type of a variable. Some times a variable name can be shortened to just the prefix and type tag, or just the type tag alone for that matter, but in most cases you'll have some descriptive text after all of that, and that text does need to be descriptive. Not that Lew's statement had anything to do with Hungarian, but since it came up in the thread, I wanted to clarify that. Pete > I have to wonder why typing five extra characters is considered any kind > of problem. It is not any kind of argument against meaningful names that [quoted text clipped - 10 lines] > Names need to be meaningful in the problem domain and to make maintenance > easier. Do not use negligent laziness as an engineering principle. This is not about saving a few characters. There is simply no advantage to having Customers.CustomerFirstName as opposed to Customers.FirstName. Customers could be a child of something else so should we have CompanyDatabase.CompanyDatabaseCustomers.CompanyDatabaseCustomerFirstName? > I'm an old Hungarian (e.g. "clsSystem") fan that came reluctantly to the > other side. > > I was told how it was no longer needed since one could just mouse over a > term to see the type. I've heard a number of Intellisense-based arguments in favor of abandoning Hungarian. Suffice to say, they don't sway me. If anything, the fact that Intellisense is strictly alphabetical just makes me like Hungarian the more. :) > However, for various reasons, everywhere in our new project the type is > appended to the object name (e.g. "SystemClass"). Well, I'd agree that's silly. > I definitely think something is needed because so many of our words are > reserved keywords anyway, but doesn't this make the argument against > Hungarian moot? I disagree with several of the points that Jeroen made in his reply, including the implication that it's okay to have variable named the same as some reserved word in the language. There a some good reasons for the "@" symbol to be used in a variable name, but IMHO none of those reasons have anything to do with hand-coded, run-of-the-mill code. Reserved words should be avoided as variable names at all costs, IMHO. > I do understand that Hungarian requires all developers to know the > 3-char prefix for every type, but the trade-off is all that wordiness > when the type is put as a suffix. IMHO, Hungarian does not dictate three-character prefixes and/or type tags. I've used four, even five characters sometimes. Just because it's Hungarian, that doesn't mean it has to be hard to figure out. In fact, the whole point of Hungarian is to make the code more transparent. There are a number of very common one- and two-letter identifies in Hungarian that are fine, because they are so common and easy to remember. But you shouldn't feel that you have to force your code into that mold, if there are longer tags that make more sense. I'm not going to get into a whole Hungarian good/bad debate here, having "been there, done that" (Google Groups will show you the thread in this newsgroup, some time ago). And frankly, it sounds to me like your question is more about whether to include the full type name as part of the variable name. Personally, I think for that specific question the answer is that it's just as silly as you seem to think it is. :) And for what it's worth, I may be the last person left using Hungarian, at least in the context of C#. But I like it, and I will continue to do so (I do it in Java too...it hasn't come up yet, but I suspect that would _really_ drive the hard-core Java crowd up the wall). Pete > I disagree with several of the points that Jeroen made in his reply, > including the implication that it's okay to have variable named the same > as some reserved word in the language. If the choice is between using "@operator" to name my operators, and not calling them "operator" because C# already has a keyword "operator" that's used for operator overloading... I'll pick what's behind door number one. > There a some good reasons for the "@" symbol to be used in a variable > name, but IMHO none of those reasons have anything to do with hand-coded, > run-of-the-mill code. The only *other* reason is when you have no choice: an object or method defined in another CLR language is carrying a name that, by some stroke of bad luck, is the same as a keyword in your language. And I'll immediately grant you that that's its primary and intended use. > Reserved words should be avoided as variable names at all costs, IMHO. Contrived names should avoided as variable names even more, IMNSHO. This is where we'll just agree to disagree, I suppose. Look, I'm not advocating for a return to the days of Fortran, where you could write down such delicacies as IF IF = THEN THEN THEN = IF And I'm not about to name every other variable "@class" or "@string". But I *will* trust the readers and maintainers of my code to not only not be confused if I use a local variable named "@operator", but actually appreciate that I didn't have to invent some meaningless suffix so as to not confuse the compiler. Good names matter. Every once in a (rare) while, your good name is a keyword. If the language has a simple and elegant way of working around that, don't mind if I use it. As a user of Hungarian, you're just spoiled by the fact that your names are *never* readable to outsiders. You have that luxury. :-) SignatureJ. > If the choice is between using "@operator" to name my operators, and not > calling them "operator" because C# already has a keyword "operator" > that's used for operator overloading... I'll pick what's behind door > number one. That was clear from your previous post. I obviously disagree, though I don't mind that. >> There a some good reasons for the "@" symbol to be used in a variable >> name, but IMHO none of those reasons have anything to do with [quoted text clipped - 4 lines] > defined in another CLR language is carrying a name that, by some stroke > of bad luck, is the same as a keyword in your language. That's not the only other reason. Another place it comes up is in computer-generated code where the identifiers are derived from some other data. Allowing the generated code a way to explicitly state "this is a variable" allows the generating code to be simpler, since it doesn't have to worry about checking for reserved words and having some fallback position. > And I'll immediately grant you that that's its primary and intended use. I don't know what the primary and intended use it. What I do know is that I disagree that a person writing code by hand should be using the "@" symbol as a normal part of their programming techniques. >> Reserved words should be avoided as variable names at all costs, IMHO. >> > Contrived names should avoided as variable names even more, IMNSHO. You and I obviously disagree with respect to what counts as "contrived". I don't find Hungarian contrived at all. To the contrary, it has a very well-ordered, predictable, and rational basis. Pete >>> Reserved words should be avoided as variable names at all costs, IMHO. >>> [quoted text clipped - 3 lines] > "contrived". I don't find Hungarian contrived at all. To the contrary, > it has a very well-ordered, predictable, and rational basis. But I wasn't talking about Hungarian at all (I'm not stupid enough to open that can of worms). Methinks thou doth protest too much. :-) I was talking about giving your variable an obvious name versus having to invent a not-so-obvious because it clashes with a keyword -- obviously, if you use Hungarian, it's just about inconceivable that you ever have that problem. SignatureJ. > But I wasn't talking about Hungarian at all (I'm not stupid enough to > open that can of worms). Methinks thou doth protest too much. :-) Fair enough. > I was talking about giving your variable an obvious name versus having > to invent a not-so-obvious because it clashes with a keyword -- > obviously, if you use Hungarian, it's just about inconceivable that you > ever have that problem. True, that. But even without Hungarian, I think it's possible to have a variable name that doesn't collide with a reserved word without the word being contrived. Human languages are usually very flexible. For sure, I've never run into a situation where exactly one English word was the only possible way to describe a particular variable. I don't think one should need to use a thesaurus to write software, but if you're having trouble coming up with non-colliding variable names, maybe that's an option. :) Pete > But even without Hungarian, I think it's possible to have a variable > name that doesn't collide with a reserved word without the word being > contrived. Human languages are usually very flexible. For sure, I've > never run into a situation where exactly one English word was the only > possible way to describe a particular variable. Of course not. That's not my point either. The point is that if there is one blindingly obvious name, I want to use that. I don't want to spend thought (however insignificant) on whether perhaps I should append -instance or -ref or prefix a- or my- or leave out a few vowels (general approaches) or find a closely related word or add in some part redundant from the context (specific approaches). C# has given me a way to avoid that and they'll pry it from my cold, dead hands! "What's a good name for this variable" is worth spending time on. "What's the second most obvious name for this variable" is not. So far, the only variable name I've ever used this way actually has been "@operator". Everything *else* in the system (the things that *aren't* C#) calls it that. It helps that I practically never use operator overloading, but even people who do would have a hard time getting confused, since the contexts are wildly different (operator overloads have a very specific syntax). Really, the only one who can get confused is the compiler. It's not like I'm deliberately looking for ways to let keywords double as variable names. I'm not going to use "bool @continue" or "double investment, @return; return @return" any time soon. I do recognize the potential for confusion, here. > I don't think one should need to use a thesaurus to write software, but > if you're having trouble coming up with non-colliding variable names, > maybe that's an option. :) If you think using a thesaurus to come up with synonyms is a good solution, it's obvious why we'll never agree on these things... SignatureJ. > [...] >> I don't think one should need to use a thesaurus to write software, but [quoted text clipped - 3 lines] > If you think using a thesaurus to come up with synonyms is a good > solution, it's obvious why we'll never agree on these things... A good solution for what? A thesaurus is a _great_ solution for coming up with synonyms. It's one of the best solutions there is. But if you're talking about "a good solution for naming variables", there should be absolutely nothing in anything I wrote that should cause you to believe that I think using a thesaurus is a good solution for that. I doubt we'd ever agree on the question at hand anyway. I don't think there's any reason to put silly words in my mouth just to justify your own disagreement. Can't you just agree to disagree without mischaracterizing my own stance? Pete >> [...] >>> I don't think one should need to use a thesaurus to write software, [quoted text clipped - 6 lines] > A good solution for what? A thesaurus is a _great_ solution for coming > up with synonyms. It's one of the best solutions there is. Yes, *obviously*. I know what a thesaurus is. Give me some credit, here. I didn't know you were going to take me *literally*. > But if you're talking about "a good solution for naming variables", > there should be absolutely nothing in anything I wrote that should cause > you to believe that I think using a thesaurus is a good solution for that. I don't. > I doubt we'd ever agree on the question at hand anyway. I don't think > there's any reason to put silly words in my mouth just to justify your > own disagreement. I'm not. I'm setting up an obvious straw man to respond to your obviously unhelpful suggestion. It's not meant to be taken literally. > Can't you just agree to disagree without mischaracterizing my own stance? I think you and I should be communicating face-to-face, not in Usenet posts. It's obvious we're not quite compatible in that medium yet. SignatureJ. > I've heard a number of Intellisense-based arguments in favor of abandoning > Hungarian. Suffice to say, they don't sway me. If anything, the fact > that Intellisense is strictly alphabetical just makes me like Hungarian > the more. :) Except then you need to know the type of something to use it. Is count going to be intCount or lngCount? The real issue with hungarian notation is that it's impossible to keep it consistant. You might, if you really struggle, get all your developers inhouse using the same standard but when you get external code it will most certainly be different. > Reserved words should be avoided as variable names at all costs, IMHO. Once I would have agreed with you but after using it I don't see what the issue is. Certainly you haven't given any reason why you think it's bad. Michael >> I've heard a number of Intellisense-based arguments in favor of >> abandoning [quoted text clipped - 5 lines] > going > to be intCount or lngCount? That's a red herring, as it's a question that only makes sense when you are misusing Hungarian. If you care, you may want to (re?)read the thread we already had awhile back on this. But the basic issue that many of the people I've run into who object to Hungarian have never actually used real Hungarian. Often their only exposure is via the incredibly wrong deviation from Hungarian that is exhibited in Microsoft's Win32 API. > The real issue with hungarian notation is that > it's impossible to keep it consistant. That's not true. If you are using real Hungarian, there is never a problem keeping your tags consistent. Consistency is a fundamental basis of Hungarian. > [...] >> Reserved words should be avoided as variable names at all costs, IMHO. > > Once I would have agreed with you but after using it I don't see what the > issue is. Certainly you haven't given any reason why you think it's bad. My personal opinion is that even with the "@" syntax, reserved words are difficult to read. Even though the compiler has no trouble, my brain cannot help interpreting them as if they are not reserved words. YMMV. Pete > That's a red herring, as it's a question that only makes sense when you > are misusing Hungarian. I don't see how. If you don't know the type of something then you will have trouble looking it up. This is probably ok if it's your own project but that just because you remember the type of most variables. > If you care, you may want to (re?)read the thread we already had awhile > back on this. But the basic issue that many of the people I've run into > who object to Hungarian have never actually used real Hungarian. Often > their only exposure is via the incredibly wrong deviation from Hungarian > that is exhibited in Microsoft's Win32 API. I'm not sure how to respond here. Are you trying to imply I have no experience with Hungarian. > That's not true. If you are using real Hungarian, there is never a > problem keeping your tags consistent. Consistency is a fundamental basis > of Hungarian. Clearly you've never worked in a team if you think there is no problem :-) Your statement "If you are using real Hungarian" says it all really because in my experience everyone has their own version. Do you have some document that specifies all the hungarian notation? Does this docuement list everything that a developer might prefix? What about instances of their own classes? > My personal opinion is that even with the "@" syntax, reserved words are > difficult to read. Even though the compiler has no trouble, my brain > cannot help interpreting them as if they are not reserved words. That's a fair point. Michael >> That's a red herring, as it's a question that only makes sense when you >> are misusing Hungarian. > > I don't see how. Because it's a misconception that the literal type of a variable is what's used for the tag. Your question presents a misuse of Hungarian, and thus isn't a useful question in the context of discussing correct Hungarian. It distracts from questions that _are_ useful, and thus is a red herring. > If you don't know the type of something then you will have > trouble looking it up. This is probably ok if it's your own project but > that > just because you remember the type of most variables. If you know _how_ the variable is used, _what_ it represents, then you know the tag. If you don't know those things, you need to learn them before working on the code. And that's true with or without Hungarian. >> If you care, you may want to (re?)read the thread we already had awhile >> back on this. But the basic issue that many of the people I've run into [quoted text clipped - 4 lines] > I'm not sure how to respond here. Are you trying to imply I have no > experience with Hungarian. You don't seem to have experience with correct Hungarian. Whether you do or not I can't say. All I can comment on in the context of replying to your previous post is that in code where correct Hungarian is used, you'd never see a variable named "intCount" or "lngCount". The name "Count" indicates to me that the variable is a count of something, which means that the correct Hungarian tag would be "cXXX" where "XXX" is the type tag for whatever it is you're counting (and may or may not actually be three characters). >> That's not true. If you are using real Hungarian, there is never a >> problem keeping your tags consistent. Consistency is a fundamental [quoted text clipped - 3 lines] > Clearly you've never worked in a team if you think there is no problem > :-) That's a really dumb statement, if for no other reason than that it's easily proven false. Not only have I worked on a wide variety of teams, the first team I worked with professionally is the one in which I learned Hungarian. It worked very well, and did not cause any problem with inconsistent tags. > Your statement "If you are using real Hungarian" says it all really > because > in my experience everyone has their own version. Do you have some > document > that specifies all the hungarian notation? Well, the definitive document would be Charles Simonyi's original thesis. I don't have a link to that handy, but Doug Klunder's write-up of the convention is IMHO more accessible anyway, and does a reasonably good job of describing the basic foundation of Hungarian. There are a number of copies floating around. Here is one: http://www.byteshift.de/msg/hungarian-notation-doug-klunder As Doug Klunder was a part of one of the original production development teams where Hungarian was actually used in practice (Multiplan at Microsoft, if I recall correctly), I would consider his description of Hungarian almost practically as definitive as the original thesis. You may find it helpful to review the Wikipedia entry on Hungarian: http://en.wikipedia.org/wiki/Hungarian_notation In particular, where I talk about "correct Hungarian", this most closely correlates to "Apps Hungarian", and the incorrect Hungarian used in the Win32 API would be "Systems Hungarian". Note also that of the opinions listed in the Wikipedia article arguing against Hungarian, they are specifically regarding the "Systems" manifestation, and since that's not correct Hungarian, they aren't useful in discussing whether Hungarian itself is useful, flawed, etc. > Does this docuement list > everything that a developer might prefix? What about instances of their > own > classes? Hungarian describes quite well how to create tags for your own data types and usages. But that's irrelevant...the examples you provided are using tags that appear to be assigned to built-in types, which is almost never correct in Hungarian (exceptions being where the data in question is used only as the built-in type itself...a common example of that exception would be the use of "b" as the type tag for a byte, as in "rgb", an array of bytes where all you care about is that it's bytes). Pete Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.