Thread: Question about pointers #2

I also think it is a good idea. How could there possibly be any disadvantages to adding a prefix?

><snip godawful hungarian notation>

I was scared to say anything when I saw that suggestion for a descriptive name, but that's close to what I was thinking. It's bad enough to see it in a Windows program, but I sure don't want to see it in a non-Windows program.

It's one of those style issues: some love it, some hate it! I wonder if we've had a Poll on it here. I know I've seen threads discussing it in the past.

but I sure don't want to see it in a non-Windows program.

GIVE A REASON WHY NOT

I can't see a downside to prefixing a variable name with it's type. It's certainly made things easier for me. I'd really like to see some disadvantages.

>I'd really like to see some disadvantages.
Okay.

1) It hurts abstraction to encode the type in everything. Let's say I have a C program that needs to be ported to C++. One of the variables is pszUserName. Well, we know that the variable contains a name, so it's probably a string, and the hungarian notation tells us that it's a pointer to a C-style string. All is well, right? No, not really. Abstraction says that we shouldn't care about the type as long as it's used according to the correct interface. There's no point in prefixing psz.

2) Okay, on to the port. Because any wise programmer will try to use std::string instead of C-style strings, the definition of pszUserName is changed to

Code:

std::string pszUserName;

At this point the programmer must make a decision. The type has changed, so she can change every occurance of pszUserName to some house standard for std::string, or leave the name unchanged and incorrect. Global changes are relatively easy these days, but there are snags for sweeping changes. Was hungarian notation really worth it if it requires so much effort to maintain?

A more realistic example is const. Say you use a pointer for a while and then later decide that it would be safer to make it const. I do this all of the time because it's convenient during development. Well, using hungarian notation you would have to change the name of every occurance of that pointer to reflect its const-ness. Can you remember to do that without fail? I can't.

3) Hungarian notation keeps track of types, but in a typed language such as C++ it's redundant. A well written C++ program will either have a declaration of the variable close at hand, or hidden by proper object-oriented techniques. With the former it's trivial to check the type and with the latter the type shouldn't matter (not to mention that hungarian notation has no prefix for such types). If a well structured program makes hungarian notation redundant, why cling to it?

4) One should be able to pronounce a variable name. This makes sense as programmers aren't left in a void to work their magic, they communicate with other programmers, often face to face. Hungarian notation makes this more difficult in a good many languages besides English.

5) Sheer obscurity. Even if you know hungarian notation, many find that reading code that uses it is harder than reading code that doesn't. You obscure the purpose by embedding information that shouldn't be necessary.

6) Inaccuracy. Hungarian notation is simply a way of commenting code. A lot of people recognize that comments aren't always kept up-to-date and are inaccurate. This is because they aren't policed by the compiler for correctness. The same goes with hungarian notation. When reading code that uses it, how can you be sure that it's correct?

7) By writing code that uses hungarian notation, you make the job of a maintenance programmer harder. But you also make your job harder (also for little gain, see above) by forcing yourself to type awkward prefixes for every name. This has a twofold effect: First, you spend extra time embedding types that could be used more effectively elsewhere and second, you focus on the type of a variable so much that it's possible to forget its use and mess something up. In this, and a few other points, hungarian notation breeds bugs.

This list is off the top of my head and far from exhaustive, BTW.

Argument from the microsoft site in favor of hungarian notation:

Speed of the decision—we cannot spend too much time pondering the name of a single quantity, nor is there time for typing and editing extremely long variable names.

Hehe.

> Speed of the decision—we cannot spend too much time pondering the name of a single quantity
If you spent any reasonable time actually designing what you wanted before writing it, the names become obvious. Perhaps the "patch-a-week" brigade would do well to learn this lesson.

Also, code is read much more often than it is written. If it's done well, it gets written exactly once. That code should be first and foremost readable is paramount to me. Anything which compromises readability (that would be HN), then its a "bad thing" in my book.

Just to add to Prelude's excellent comment
Why not just get rid of the cryptographic nature of hungarian and say what you mean
const char *pszName;
would become
const char *const_char_pointer_Name;
It is at this point you realise that the type declaration is essentially repeated information. So why not just say
const_char_pointer_Name;
and let the compiler figure out what you meant. Unfortunately, this language is no longer 'C'. If you want to write a compiler for this new language, that's up to you.

> 2) Okay, on to the port
Yes, because the 'L' in LPSTR is now completely meaningless in a 32 bit context.
But no you can't get rid of it, it's just some meme virus that will refuse to go away for many many years to come. New generations of programmers will wonder what it means and various folklore tales will emerge to explain it.

A couple of more reasons
1. Primitive types are first class, everything else is second class.
So pointers, ints, chars etc all get their own special letter. But what about all your structs, classes and typedefs?
Do you go with something meaningless like say 'C' for all classes (that's really informative)
Or do you smash your way through the abstraction and reveal the underlying types.

2. No-one can seem to agree on all the letter combinations, even within a local organisation. Common letters get reused for all sorts of purposes. Depending on context (which you can only really get by going and looking at the actual declaration - oops, we wanted to avoid that), 's' could mean say 'signed' 'struct' 'string'

Having read Simonyi's original description, I came to the conclusion that the whole idea was akin to training wheels on a child's bycicle. Fine when you're learning not to fall over, but utterly useless once you're experienced enough - they simply get in the way!!!

Ok, I see where you're coming from. However, in my experience those disadvantages have not had any effect on my programming. It takes little to no effort to put in hungarian notation in the way that I do, and I firmly believe that it increases the readability of my code. I think it takes a bit of pedantacy to really care.

To whoever gave me the bad reputation for my capitalized post earlier, I was annoyed that Prelude and other people were making bold statements without providing any examples or proof.

>It takes little to no effort to put in hungarian notation in the way that I do, and I firmly believe that it increases the readability of my code.
We weren't trying to force you not to use hungarian notation, just explaining why many people disapprove of it. If it works for you then so be it, but it never hurts to hear the other side's arguments so that you can better defend your own position. Rest assured that in a serious code review, you'll probably be called on your naming scheme and have to give a detailed account of why you use it.

>To whoever gave me the bad reputation for my capitalized post earlier

Now why didn't I think of that?