hungarion notation

u should do a search.
thers about 20-30 threads on this subject.

It is bad because:
1. Looks ugly (I hate variables with capitalized and non apitalized letters).
2. Can be ambigous. For example, IntSomeCounter is 32 bytes on some platforms, but on others it can be 64 (or maybe even 16).
3. If you decide to change the variable type, you will have to change it's name all over. Most of the people are too lazy to do that, so you will have a float variable that will have int in it's name.

Hungarian notation is a system of encoding type information in variable names by prepending different characters to the name invented by Simonyi while he worked at Microsoft. (Does anyone know if he's still there or not?) For example a variable prepended with ul might mean it's an unsigned long.

I personally dislike Hungarian notation, and strongly recommend against it's use in new projects. Here's one article by authors who aparantly agree with that sentiment.

Microsoft commisioned Charles Simonyi (who is Hungarian) to come up with a set of conventions that all MS programmers would follow when writing code, so that other MS programmers could tell the types of variable names by the variable names themselves.

Examples being:

char cMyChar;
int iMyInt;
const int c_MyConstInt;

class CMyClass{...};

etc.

The benefit is that if you're skimming your own code (or anyone's code who follows this method for that matter) you can tell what a variable's data type is w/o having to look for the declaration. Makes things a little faster.

I like it, but a LOT of people don't like it. =) Everyone has their own system, so just find something that works for you.

Unless you intend to get a job for Microsoft.

The prevailing ideas at the moment seem to be that:
1) Complete hungarian notation sucks.
2) Even prepending partial types, f for float/double, i for short/int/long/__int64, etc. is considered dumb.
3) Scope indicators are good. It doesn't really matter what these scope indicators are, as long as you have a consistent way of indicating globals and member variables.
4) The "C" prefix for class types is increasingly falling out of favor, as it's essentially a lazy way of doing: CClass Class; without having to think of an actual name for an object.

Let the flame war begin!

Hungarian notation is the technique of encoding additional info about a variable in its name. For example, m_lplpbDoh is a member variable that is a long pointer to a longer pointer to a bool (or BOOL).

Sometimes it is helpful, most of the time (in my opinion) it is not. I generally add the scope to a name because that is the hardest to determine from the context. The rest is usually obvious or unimportant and just clutters the code making it harder to read.

How long since the last one? A month?

oh wow it turns out I have been doing hungarion notation.

Quote:

Original post by serratemplar Microsoft commisioned Charles Simonyi (who is Hungarian) to come up with a set of conventions that all MS programmers would follow when writing code, so that other MS programmers could tell the types of variable names by the variable names themselves. Examples being: char cMyChar; int iMyInt; const int c_MyConstInt; class CMyClass{...}; etc. The benefit is that if you're skimming your own code (or anyone's code who follows this method for that matter) you can tell what a variable's data type is w/o having to look for the declaration. Makes things a little faster. I like it, but a LOT of people don't like it. =) Everyone has their own system, so just find something that works for you. Unless you intend to get a job for Microsoft.

Actually I remember reading some MS documentation or maybe it was a book not long ago that acutally recommended that you not use except for maintaining old code.
So I think it has gone the way of disco and bellbottoms no?
Didn't we have a couple of people around here working for MS and I know they were saying that almost all new programming was done with c#,etc so you should see less and less of hungarian in the future so I wouldn't start using it.

[Edited by - daviangel on July 15, 2004 10:16:54 PM]

That'd be funny if that were true. =) I wouldn't be surprised if it was.

Quote:

Original post by daviangel Actually I remember reading some MS documentation or maybe it was a book not long ago that acutally recommended that you not use except for maintaining old code. So I think it has gone the way of disco and bellbottoms no?

The "official" Microsoft .NET Class Library Naming Guidelines specifically advice against the use of Hungarian Notation.

I use a small subset of hungarian notation: I put a m before member variables, x before parameters, and l before locals. Everything else, such as classes, functions, and properties (C#) are just plain CamelCase.

Quote:

Original post by serratemplar Examples being: char cMyChar; int iMyInt; const int c_MyConstInt; class CMyClass{...}; etc.

Poor examples. Hungarian notation was developed within the context of assembly language programming, where variable identifier names were limited (many early assembly environments limited line length to 64 characters, including comments) and where type was a non-existent concept. Its subsequent application to contexts outside of thise which righted those wrongs (including modern assembly environments, sometimes with the help of macros) is a sin from which the world has not recovered.

Quote:

Unless you intend to get a job for Microsoft.

Microsoft presents several alternatives.

In ASM they do make sense, but why did they 'port' the concept to higher level languages, such as C and C++?

Well, for starters - only newer compilers will give you a tooltip that displays type information (and more) on mouse over. This means that you no longer have to rely on warts or looking back through source code to find info on a variable's type.

Much smarter, if you ask me :)

Intellisense rocks!!!

Anyway, I only use any kind of notation for scope. I can easily determine the type of the variable, but the scope can get confusing, especially when passing parameters (where there are multiple vars with similar names)...

Hungarian Notation is the difference between great code and okay code. I want to know the scope and type at first glance, without holding my mouse over every variable to figure it out. It increases readability, and if it weren't a Microsoft thing, I'm sure it'd be more appreciated by Linux zealots who refuse to use it simply because of its Microsoft roots.

I'll take Hungarian Notation over Camel Notation anyday.

createGuiAndStuff()

Oh yeah, thats REAL attractive.

If you can't correctly guess the type of some symbol just by its name, it's a bad name. That, and the described purpose of the namespace to which it belongs, should be enough context to convey the attribute's meaning.

Type information isn't the slightest bit useful. (not to me, anyhow) Meaning is always more useful. A counter may be an int, but an int could be anything from a quantity to an opaque, implementation-defined handle.

Hungarian is utterly useless except for describing "how", which is not nearly as important as "what" and "why".

The different types you can have are:

local variables
member variables
global variables

If you don't know what type your local variables are and have to keep scrolling back up the page to see their definition then your functions are too big. Break them up into smaller functions. Also combine individual variables into classes and move operations onto the class.

If you can't remember what all your member variables are then maybe the class is too big. Or maybe you should only access them through other functions which do something rather than relying upon the type.

If you have global variables... well there's not much more I can say about that (search the forums for 'petewood singleton' or something).

The hungarian notation came into it's own when people needed to remind themselves of information that the compiler couldn't check. E.g. a C string could be terminated with a zero, or not terminated. These things made a big difference to program correctness. So reminding yourself that you were holding a pointer to a zero terminated string was important. The pointer was also a long (32 bit) pointer so you'd get the wart lpsz - a Long Pointer (to a) String (with a) Zero, e.g. lpszName. This was actually useful in an environment where you needed to know that information and the compiler couldn't enforce it.

Now that we can encapsulate ideas in classes we can have a String class and not need to worry about such things. A function will just want a String passed to it. You can get on with calling the string 'name'.

LPCSTR lpszName = "petewood";
String name = "petewood";

As far as I can see, the application of warting to strings was its one benefit. And that's gone now.

Also that Conversation with a Guru about warthogs is worth reading.