I found it handy at the time, but now that I work in more strongly typed languages I find the type-embedding version of Hungarian more actively harmful than actually useful. View all posts by Herb Sutter. There may be another reason to use Hungarian notation.
If you are writing MFC code which is already hungarian, you need to use some convention which looks consistent with the library code. This does not hold true for STL like libraries as we are users of the STL code most of the time rather than extenders. A partially specialised mutex template using that type trait could select best mutex use.
In general I use the pData notation for pointers, and this seems very logic to me. Noone else writes this, too? I find it helps both the writer and reader. If a property changes from being a pointer, the use of the property changes in most cases and needs to be updated.
The point is that the IDE will tell you stuff when you are writing, but not when you are reading. Variable names are for the code reader, not just the compiler. Most people read code more often than they write it. The variable declaration is often far away from its usage. Having the type embedded in the name saves people from having to dig around for the declaration. People who love Hungarian, let me ask you something. Have you tried programming without it?
Have you used any managed languages like C or Java. Have you used Hungarian in those languages? And I understand your affection for Hungarian. But my experience is, it makes the code less readable bBool, szString; pszString, and so on and for a fact after time they start to lie. Member variable is different from local variable, etc.. The reason they agree here is because most of them have never used Hungarian notation correctly.
I started coding pretty much the about the time Hungarian notation was invented and the first time I was forced to use it on a project I hated it. After a while I realised that when it was done properly it did actually help and these days I love it. At my work, we code in Java, but the founder cames from MFC world, so use similar code style aligned braces, I like this!
And they said all variables should have a prefix showing its type eg. Which shown as being a bad idea, as the types can change but the names doesn't follow, or coders are not consistent in the use of these prefixes I even see aBuffer, theProxy, etc.! Personally, I chose for a few prefixes that I find useful, the most important being b to prefix boolean variables, as they are the only ones where I allow syntax like if bVar no use of autocast of some values to true or false.
When I coded in C, I used a prefix for variables allocated with malloc, as a reminder it should be freed later. So, basically, I don't reject this notation as a whole, but took what seems fitting for my needs.
And of course, when contributing to some project work, open source , I just use the conventions in place! Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Why shouldn't I use "Hungarian Notation"? Ask Question. Asked 13 years, 1 month ago. Active 6 years, 4 months ago. Viewed k times. Related: stackoverflow.
Active Oldest Votes. Mark Stock. Nice analogy, although slightly unfair. In that sentence, both Using and Reading are gerunds. But I get the point you were making Chris Noe: for certain reading styles parse the prefix and the suffix with a glance at the middle , your example only makes things worse.
I see "vUsing" and hear "voosing" in my head. Jon: if you have a variable name that does not fully give away what it is representing, then by absolutely all means the focus should be to rename it to something more descriptive and Hungarian notation is not an improvement, in the very, very best case it is fixing the symptom - not solving the problem. Show 6 more comments. Most people use Hungarian notation in a wrong way and are getting wrong results. Good link, a good summary of what's behind the link, and no fanaticism.
Note that Joels example is in VBScript, a language that long didn't have user-defined classes. Microsoft is known for its past misuse of Hungarian notation. Prepending type information to identifiers is not only useless but it may actually do harm. First, readability is less fluent. Second, in languages that support polymorphism or duck-typing the wrong information is passed. Krumia: This would typically be prevented by having descriptive variable names in the first place. But if you want to be sure, it would be much safer to create distinct types eg.
Show 8 more comments. Joel is wrong, and here is why. A lot of the things that Joel talks of as "kinds" are not kinds; they are, in fact, types.
The intent of the variable should be encoded within the type of the variable, not left to something so fragile as a frigging naming scheme. AppsHungarian is a pragmatic method to highlight problems when using these languages in an obvious ways to programmers viewing the code, rather than examining the bug reports.
DrPizza: I believe you have missed one of the very important points that Joel is making while advocating Apps Hungarian: this notation is just a very pragmatic tradeoff.
Making the compiler capable to see "wrong code" is a great goal, but is it always worth its cost? DrPizza: Joel is wrong , and What most languages lack, however, is a type system that's expressive enough to enforce these kind of distinctions. So, since most languages do lack the expressiveness enough to enforce these kind of distinctions, Joel is right.
Show 15 more comments. I think it massively clutters up the source code. Good call. If you use it for type, then yes, it's useless. It's useful to impart other information. Shog9: I think you did not understand the Apps Hungarian Notation. It's more about sFirstName vs unFirstName safe vs unsafe, unsanitized , this way you know something more about it.
Convention is ok, but more often compilation enforcements are better. Show 1 more comment. Languages with user-defined types do not make it always practical to use types instead of "kinds". Consider prefixes "c", "d", "ix" from Joel's Apps Hungarian. Do you use custom integer types for those, in every modern languages? I don't think so.
Because modern languages still do not have builtin custom integer types for indices, counts, and differences between two numbers. As long as we are still using vanilla ints, Apps Hungarian will be non-redundant and useful.
Add a comment. Don't knock it until you've tried it. Encoding signedness into variable names is great when the piece of code is actually dealing with signedness. Using that as an excuse to enforce the convention for all variables is just domatism IMHO.
You have a good point with member variables, though. It's just a trick to help productivity. Just like IDE autocomplete. There is nothing fundamentally evil about it. I believe that experienced coders must be allowed to use their own style. Forcing anyone to choose a certain style is bad.
I work as as a single developer now, but I would not enforce a style on anyone I worked with unless they lacked a consistent style in the first place.
So, you're using the a naming convention to filter the variables, huh? I must agree that it is kinda clever. Rarely the type unless it is the semantic. I hope that made sense. TL;DR:I'd still stick to naming variables according to what they represent than how they're represented. I upvoted this back then since I was in favour of Hungarian. Now I regret it, and would never go back to prefixing something to a variable..
Show 4 more comments. I naturally comprehend that a variable called name is a string, and a variable called i or count is an int. Does one really need sName and iCount? How does it really help? I would argue that your product id example is a special case, and maybe there it would be fine.
But even then, being consistent and representing product IDs with ints or strings everywhere would be a much better solution, no? The whole naming thing seems like a cop-out. It's for consistency. Yes, "name" inherently implies a string. But what would you presume "userid" to be? A GUID? Even something like "acctno" could have a value of 42 or "23X". Documentation is sparse enough in most code.
This standard helps the maintenance programmer along a bit. David I absolutely agree with your answer - knowing at a glance the intent of the variable is the reason I prefer prefixing as well, more so in a dynamic language like JS.
Paul Tomblin. Isn't scope more important than type these days, e. Then again, the code probably shouldn't be depending on scope so much. It's no surprise that there was a backlash against this sort of thing. Clearly, more descriptive names are almost always a benefit. The type of the variable also provides a significant portion of its meaning.
It's a matter of having as much contextual information presented with the least amount of friction. Hungarian notation does this for strongly typed languages. WorldMaker on Sept 1, root parent [—]. I don't think that the strength of a type system is an orthogonal concern at all. Much "weaker" dynamically typed languages typically don't see a need for it Python, JS and much stronger typed languages don't see a need for it C , ML family, Haskell. If anything, I think Hungarian notation is orthogonal to descriptive names.
Sure, sometimes the type of something is useful descriptive information though I'd argue rarely, even in strongly typed languages , but typically it's answers to the question "what is this variable for?
Type information is pretty much never an answer to either question, it's much more to do with the mechanics of how the variable might accomplish its goals than what said goals actually are [1].
Certainly Hungarian notation has its places, and I'm not going to argue that it hasn't been useful in the history of languages, but I will argue that it's place in history is more as a historic tooling-related footnote than anything else.
0コメント