hungarian notation, anyone use it?

all the time!!

I find useing m infront of class member variables to be essential documentation!

Cheers
Chris

Quote:

Original post by wasted_druid Just wondering if anyone out there uses hungarian notation. I personally never liked it, but has anyone found a good use for it?

Yes. Apps Hungarian was a Good Idea™, especially for the time. Systems Hungarian was a disaster.

Edit: More details.

It was useful, sometimes, for C. It is not useful for C++.

Oh.... Lord no... not this subject again [crying]

Quote:

Original post by Oluseyi Quote: Original post by wasted_druid Just wondering if anyone out there uses hungarian notation. I personally never liked it, but has anyone found a good use for it? Yes. Apps Hungarian was a Good Idea™, especially for the time. Systems Hungarian was a disaster. Edit: More details.

Awesome link man. I completely agree.

Hungarian notation was getting pretty popular for a while, until a few outspoken software developers revealed its flaws. Now, two years later, it is practically looked down upon. Heh.

The purpose of hungarian notation is to let you see what type a variable is without looking at its definition.

There are several (free) IDEs that will happily tell you what type a variable is, without the user having to decipher gibberish.

If you're using any templated code (including any std containers) then you won't be able to embed anything useful in the prefix without getting into the area of 5+ char prefixes.

Hungarian notation is clearly obsolete. Add to that the fact that it's a nightmare to maintain and that it breaks the one definition principle.

Quote:

Original post by Nitage The purpose of hungarian notation is to let you see what type a variable is without looking at its definition. There are several (free) IDEs that will happily tell you what type a variable is, without the user having to decipher gibberish. If you're using any templated code (including any std containers) then you won't be able to embed anything useful in the prefix without getting into the area of 5+ char prefixes. Hungarian notation is clearly obsolete. Add to that the fact that it's a nightmare to maintain and that it breaks the one definition principle.

Plus it's hideous

Quote:

Original post by Verg Quote: Original post by Nitage The purpose of hungarian notation is to let you see what type a variable is without looking at its definition. There are several (free) IDEs that will happily tell you what type a variable is, without the user having to decipher gibberish. If you're using any templated code (including any std containers) then you won't be able to embed anything useful in the prefix without getting into the area of 5+ char prefixes. Hungarian notation is clearly obsolete. Add to that the fact that it's a nightmare to maintain and that it breaks the one definition principle. Plus it's hideous

There's always that.

Quote:

Original post by wasted_druid Just wondering if anyone out there uses hungarian notation.

No.

Quote:

I personally never liked it, but has anyone found a good use for it?

No.

Quote:

Original post by Nitage The purpose of hungarian notation is to let you see what type a variable is without looking at its definition.

Wrong.

The intent of the original Hungarian Notation (aka Apps Hungarian) was to indicate the usage of the data in a variable as a means of promoting good code. Read the links I provided for more information. Unfortunately, Charles Simonyi was Hungarian, so he used the word "type" where he clearly meant "usage," and even though the text of his paper made his meaning clear, it was still misunderstood by the legions who created what is known as Systems Hungarian or Anti-Hungarian Notation.

Apps Hungarian is useful in dynamically typed languages; Systems Hungarian is not. Apps Hungarian provides information that resides in the application design, not the code; Systems Hungarian does not. Apps Hungarian allows code to grow, such as changing the actual type of the variable; Systems Hungarian does not, leading to travesties such as lparam in the Win32 code tree (which should be dwparam since the conversion from 16 to 32 bits), a legacy of Win16.

The great problem of Hungarian Notation is that most people are familiar with A-NH or Systems Hungarian thanks to the books of Charles Petzold, but not aware that that is a complete misapplication of the system. They rightly reject this system as unproductive and detrimental to code quality, but wrongly lay the blame on Hungarian Notation as a whole.

Apps Hungarian is a Good Thing™.

MFC uses it. I remember that a saw an explaination about it in the book Programming Windows with MFC.

I use hungarian. I like having a naming convention. There are ceratinly worse habits that some programmers have.

Quote:

Original post by Oluseyi Quote: Original post by Nitage The purpose of hungarian notation is to let you see what type a variable is without looking at its definition. Wrong. The intent of the original Hungarian Notation (aka Apps Hungarian) was to indicate the usage of the data in a variable as a means of promoting good code. Read the links I provided for more information. Unfortunately, Charles Simonyi was Hungarian, so he used the word "type" where he clearly meant "usage," and even though the text of his paper made his meaning clear, it was still misunderstood by the legions who created what is known as Systems Hungarian or Anti-Hungarian Notation. Apps Hungarian is useful in dynamically typed languages; Systems Hungarian is not. Apps Hungarian provides information that resides in the application design, not the code; Systems Hungarian does not. Apps Hungarian allows code to grow, such as changing the actual type of the variable; Systems Hungarian does not, leading to travesties such as lparam in the Win32 code tree (which should be dwparam since the conversion from 16 to 32 bits), a legacy of Win16. The great problem of Hungarian Notation is that most people are familiar with A-NH or Systems Hungarian thanks to the books of Charles Petzold, but not aware that that is a complete misapplication of the system. They rightly reject this system as unproductive and detrimental to code quality, but wrongly lay the blame on Hungarian Notation as a whole. Apps Hungarian is a Good Thing™.

I read the link. He seems to be saying that, instead of using a robust type system, you should use simple types with a usage prefix.

The only time that's a good idea is when you can't make a robust type system (like if you're using C). If you're using an OO langugage there's simply no excuse for this type of thing (like MFC).

I accept that such a scheme may be beneficial in a dynamic language, but most games (at least the engines) are written in statically typed languages, and this is a game development forum.


If you followed that methodology then you wouldn't use ostreams and istreams - you'd just use a general stream and put i or o in front of the variable names.

This makes it easier to make mistakes, as the compiler can't catch them for you, which in turn leads to worse, less maintainable, code which is exactly the opposite of the what hungarina notation is supposed to achieve.

Wow, so none of you use m to indicate a member variable of a class, that is the best use of Hungarian notation I've seen.

Sounds like I'm treading my own path here;)

I also perfer hungarian in langauges like vb and Objective C where you don't have to declare a variable type, you can just say dim var and it can represent anything.

I will often use dim strVar to indicate that this variable will hold a string.

Cheers
Chris

Quote:

Original post by chollida1 Wow, so none of you use m to indicate a member variable of a class, that is the best use of Hungarian notation I've seen. Sounds like I'm treading my own path here;) I also perfer hungarian in langauges like vb and Objective C where you don't have to declare a variable type, you can just say dim var and it can represent anything. I will often use dim strVar to indicate that this variable will hold a string. Cheers Chris

I always use the m_ prefix to indicate a member variable, and the g_ prefix to indicate a global variable. m_ and g_ don't indicate type - they indicate scope. Big difference.

Why would you prefix a non-typed variable with a type? Conceptually, you are assigning a type to a variable that is not supposed to have one. It seems like are voiding the whole purpose of non-typed variables :).

Quote:

Original post by chollida1 Wow, so none of you use m to indicate a member variable of a class, that is the best use of Hungarian notation I've seen.

That's not Hungarian notation.

Pardon?? I must be confused. I thought hungarian notation's definition has now evolved into any leading text that indicates what the type of a variable is.


According to this site http://web.umr.edu/~cpp/common/hungarian.html "m_" is part of Hungarian notation. ANd since its on the internet it must be true:)

How do you define it??

Cheers
Chris

Quote:

Original post by Oluseyi The intent of the original Hungarian Notation (aka Apps Hungarian) was to indicate the usage of the data in a variable as a means of promoting good code. Read the links I provided for more information. Unfortunately, Charles Simonyi was Hungarian, so he used the word "type" where he clearly meant "usage," and even though the text of his paper made his meaning clear, it was still misunderstood by the legions who created what is known as Systems Hungarian or Anti-Hungarian Notation.

Which, was not programmers, but the documentation team (see second link).

Quote:

Apps Hungarian is useful in dynamically typed languages; Systems Hungarian is not. Apps Hungarian provides information that resides in the application design, not the code; Systems Hungarian does not. Apps Hungarian allows code to grow, such as changing the actual type of the variable; Systems Hungarian does not, leading to travesties such as lparam in the Win32 code tree (which should be dwparam since the conversion from 16 to 32 bits), a legacy of Win16. ... Apps Hungarian is a Good Thing™.

Sometimes, although I am not a big fan of apps hungarian either. I would rather see long descriptive names though (well, long according to some people...).

Quote:

Original post by chollida1 Pardon?? I must be confused. I thought hungarian notation's definition has now evolved into any leading text that indicates what the type of a variable is.

No, that's "using prefixes". It's been around a lot longer than hungarian notation, or even C, has.

Quote:

According to this site http://web.umr.edu/~cpp/common/hungarian.html "m_" is part of Hungarian notation. ANd since its on the internet it must be true:) How do you define it??

Well, Petzold-style Hungarian Notation (a.k.a. A-HN, "systems Hungarian", "type warts", etc.) doesn't really apply, since the m_ doesn't refer to type. Simonyi-style Hungarian Notation ("Apps Hungarian") comes a little closer, since it talks about semantics instead of type, but m_ and friends really refer to scope and binding, not to semantics. And from a purely syntactic point of view, m_ is clearly not "classic" Hungarian Notation because classic HN does not use underscores.

It's all semantics, of course, and it's even worse here because of Simonyi-style-HN apologists trying like heck to differentiate Systems HN from Apps HN. So if calling it HN floats your boat, go for it; it would be hard to confuse the issue more than it already is. But if you were to ask Simonyi or Petzold if m_ was part of THEIR HN, they'd each say no.