I just started programming in windows and I already HATE hungarian notation

quote: Original post by Kylotan

Original post by Magmai Kai Holmlor
Your functions should generally be short enough so that you can see your local variable declarations onscreen 90% of the time. Especially so in C++, where you can (and probably should) declare variables near they are first used, rather than at the top of the function. I find that I very rarely need to write functions that don''t fit on the screen, and when I do, it''s because they are heavily commented, which is just as useful as these naming conventions.

You must use a damn drive in movie screen for a monitor

Personally I dislike full-on hungarian notation, since it confuses the actual purpose of the code with (IMHO largely unnecessary) type information. Minimal, sensible use for denoting pointers, scope is fine, but variable names like agsczxcvfEmployeeName (silly example, but I am sure you have all seen variable names a bit like this) certainly DO NOT make readable code. And I tend to agree that functions should be kept reasonably small, so the type info should never be more than a couple of presses of the page up key away.

That said, anyone working on a project as part of a team should always decide on some basic coding conventions right at the start, and everyone on the team should stick to them throughout.

quote: Original post by CHollman82

You must use a damn drive in movie screen for a monitor

Nah, just short functions and reasonably high resolution Either way, if a function has too many variables for you to remember what they are, it''s too big. That''s the rule I work by. Generally, if you need a load of variables, they should be inside some sort of class or struct anyway, in which case that context will help remind you what they are.

Also using things like the STL help keep your code short.

I usually use p for pointer (pMap) but that''s about it.

Hungarian notation is stupid. Can you really tell me what type ms_A_lprtf_jdska_myScore is?

Besides, the IDE will tell you a variable''s type if you hover over it.

quote:
Your example is flawed, because I couldn''t care less about the member variable aspect if I''m not using C++

No, that doesn''t make it flawed. It''s still a perfectly good example. And for those who use straight C you still don''t know whether the variable is local, global, or file (basic equivalent of C++ member variable) scope.

quote:
I don''t care whether it''s a byte/dword/whatever because current processors and compilers will optimise to handle dword quantities.

No, not all compilers will optimize this way, and to automatically assume they will is a bad thing. Besides you can/will turn those optimizations off for some very good reasons (ie, small tcp/ip packets).

quote:
so I have to solve a simple unsigned/signed warning - do I care?

If you were working on a very large project for a company you''d care. Having to recompile because of a warning can be a very COSTLY thing to do. Even with my 700Mhz at work doing a full recompile of our application takes over 30 minutes. And it takes over an hour on some of the slower machines...

Besides you''ll only get a compiler warning if you are trying to fit a larger variable type into a smaller variable type, and not the other way around, so you can''t rely on the warnings

quote:
Also, someone said Hungarian helps deal with the scope. And granted, projects do get big, and knowledge of where your variables are declared is helpful, BUT, if the code/module/project is designed and implemented properly. These things should be obvious without the prefix.

And how do you make your variable obvious that it''s an unsigned int member variable without using HN or some derivative of?

quote:
Nah, just short functions and reasonably high resolution Either way, if a function has too many variables for you to remember what they are, it''s too big. That''s the rule I work by. Generally, if you need a load of variables, they should be inside some sort of class or struct anyway, in which case that context will help remind you what they are.

Yes, short functions and a high resolution SHOULD keep your function all in your screen, however not everyone uses a large resolution. Remember that Hungarian Notation is especially useful for other people looking at your code, or you looking at other peoples code.

quote:
Hungarian notation is stupid. Can you really tell me what type ms_A_lprtf_jdska_myScore is?

If you actually used Hungarian Notation in your example, then yes, I could EASILY tell you what it is. How is that stupid?

quote:
Besides, the IDE will tell you a variable''s type if you hover over it.

Not all IDE''s have this feature so people looking at your code may be SOL. Besides that fact I find it much, much faster to just glance at a variable type and know what it is rather than looking at it, putting my mouse pointer over it, and then waiting that second or two for the tooltip to popup. Doing that for 3 or 4 variables in a row gets rather annoying. Just a personal opinion tho.

Also tooltips don''t tell you whether the variable is local, member, or global.


- Houdini

What I''d like to know is how many of those that don''t use HN or any kind of coding standard have worked on a team that managed several hundred thousand lines of code and how they kept it all straight? If I was subjected to that I''d be looking for a new job in a heartbeat. It''s just unacceptable.

I have never regretted using a coding standard when working on a project as part of a team. I actually forced people on a team to start using a standard because their code was totally unreadable. Stuff like:

text = name

within a VB program is totally useless. What are "text" and "name"? Are they textboxes, strings, objects? There was no way of telling from the context either. That''s just plain stupid. C/C++ code becomes even more unreadable when no standard is used.

Breakaway Games

damn.. use it if want to ... if you don''t then don''t.. some people try WAY to hard to make others believe their view is right.

Wake up call!

Ok everyone, I have to set a few things strait, and then add my own subjective 2 cents.

First, m_, g_ are NOT hungarian notation.

Hungarian notation is a notation for prepending concreate type information to a variable''s name, such as pCount, szName, ppBuffer. Someone said earlier that hungarian notation was very "c++" something he hated. How absolutely WRONG! C++ (OOP) is about DATA HIDING and ENCAPSULATION. The ENTIRE point is to not know or think about anything you don''t need to know. This reduces dependencies by it''s very nature. In this sense, hungarian notation isn''t good or bad based on how hard or easy it is for text editors and compilers to do things for you, it''s good or bad based on how you think. The entire idea of polymorphism and object oriented programming is to allow people to think in terms of INTERFACE ... not implementation. So if what you want to do is write an algorithm to computer and display some mathmatical output, you need to know the type of that output in ONE place, where you declare the variable ... everywhere else can assume that decision was made correctly and simply use the interface, such as the overloaded operators. Look at the diff between c and c++ i/o and you will REALLY see the change. C uses a hungarian concept for printf (which is how many of the hungarian prefixes were chosen in the first place), C++ hides this information, cause YOU don''t need to know it ... the compiler does.

Now ... as for the g_, m_ labels ... these are neither good nor bad ... they tell you scope information, which may be helpful, and is DEFINATELY helpful while first trying to understand complex code someone else wrote (if folowed religiously they tell you properly how to track that variable, as a global, etc etc -- but the system breaks down in certain places because it fools you if someone names a static (class) variable m_ ... then what good is it ... sure it''s a member of the class .. but that''s evident by scope lookup rules ... it fools newbies into thinking it belongs to the instance) anything that can be easily misinterpreted should be suspect.

As for the p_ label ... absolutely hogwash. It tells you that the compiler thinks of it as a pointer ... which the declaration already tells you ... and it adds ZERO information ... who OWNS this variable ... what is it''s scope ... and in the case of 2 level deep pointers .. such as ppStruct ... it tells you the syntax for derefrencing .. which the compiler will catch anyway ... but does not clue you in on VALID operations ... are you allowed to dealloc and replace ... is it in an array? etc etc.

A good naming convention is the most important thing you can have (second to a well thought out design), but MORE naming convention does NOT mean better. Someone laughed at the poster who said (paraphrase) "if you cannot remember the type, you probably named the variable poorly" ... but that statement is true -- IN context! In a certain context, the name of the variable should prompt you to remember the interface, OR give you enough information to look the interface up.

Variable names like: playersName, livesRemaining, highScore, analRententiveAliensVanquised, should provide more than enough info to anyone who has any business reading the code ... and when it comes time for the AI guy or level writters to interface with your code, it will be much easier for them than: szPlayersName, cLivesRemaining, dwHighScore, lAnalRetentiveAliensVanquised. Now, I''ll admit, if they are accessing your stuff from a different language, they will need some form of document like a Data Format Desription, but they need this anyway ... which will tell them valid ranges, little/big endian, initial state, etc.

So ... do what your gonna do ... but my 2 cents is this:

The only way to allow human beings to understand and develop more complicated systems is to either: a) allow them to develop subsystems in isolation, b) allow them to deal in higher levels of abstraction. We use (a) all the time, breaking the program into modules, dividing work amoung people, and RIGIDLY defining their connecting points. (b) is also used all the time ... hence the creation of HEADER FILES ... UML diagrams ... polymorphism

... so WHY do the proponents of hungarian notation want to force this already readily availible information (look up the declartion when necessary - which exactly matches the TRUE compiled code - no chance for version errors) to be viewed and constantly remembered by the programmer. If I one day solve the problem of deciding I need exactly 16 bits of information for my ''highScore'' variable ... then I will never need to think about that decision again unless one of 2 things happens: a) i am setting the variable from a larger variable that wont fit (my compiler will warn me and bring this to my attention .. then I will have to make a decision), b) I am modifying the value mathematically, and I need to worry about boundry conditions (but whenever ANY algorithm works on values the writter must consider these issues ... and in much greater detail than 16/32 bits .. he needs to think in terms of initial values ... all posible events ... possibly outcomes) SO ... I say .. quit using a system that feels like it provides benifits that it doesn''t ... a false sense of security will get you into more trouble than would facing the situation knowing you need to know more details in some situations .. but in others you don''t care at all.

Oh well ... hope someone finds this post thought provoking, not just provoking.

quote: Original post by Xai

First, m_, g_ are NOT hungarian notation.

m_, g_, l_ are considered part of Hungarian Notation. Whether or not they were part of the original design they''ve been included in every HN table I''ve ever seen.

quote: Original post by Xai
Now ... as for the g_, m_ labels ... these are neither good nor bad ... they tell you scope information, which may be helpful, and is DEFINATELY helpful while first trying to understand complex code someone else wrote (if folowed religiously they tell you properly how to track that variable, as a global, etc etc -- but the system breaks down in certain places because it fools you if someone names a static (class) variable m_ ... then what good is it ... sure it''s a member of the class .. but that''s evident by scope lookup rules ... it fools newbies into thinking it belongs to the instance) anything that can be easily misinterpreted should be suspect.

Because someone can not use HN properly doesn''t mean it shouldn''t be used. That''s like saying you shouldn''t comment because code changes and you may forget to change a comment and then your comment/code won''t match, which will fool newbies.

When you use HN you document the standards for member, static, global, integer, etc, which you follow religously and the newbies should read before ever looking at your code.

quote: Original post by Xai
As for the p_ label ... absolutely hogwash. It tells you that the compiler thinks of it as a pointer ... which the declaration already tells you ... and it adds ZERO information ... who OWNS this variable ... what is it''s scope ... and in the case of 2 level deep pointers .. such as ppStruct ... it tells you the syntax for derefrencing .. which the compiler will catch anyway ... but does not clue you in on VALID operations ... are you allowed to dealloc and replace ... is it in an array? etc etc.

pdwHighScores; That''s a local variable, that''s of type DWORD and is a pointer to an array. Just saying pHighScores is not proper HN.

quote: Original post by Xai
A good naming convention is the most important thing you can have (second to a well thought out design), but MORE naming convention does NOT mean better. Someone laughed at the poster who said (paraphrase) "if you cannot remember the type, you probably named the variable poorly" ... but that statement is true -- IN context! In a certain context, the name of the variable should prompt you to remember the interface, OR give you enough information to look the interface up.

I''m assuming you''ve never worked in a large company on a program that was not written by you. Because there is no way you can "remember" the interface if you''ve never seen the code. And if it is a member variable that is declared in the base class (7 classes deep) and you''ve never seen the code then you have no idea what type it is, or in which file it is declared in. Hence you have to find/search through all 7 classes to find the declaration. And yes, this HAS happened to me at a job before.

quote: Original post by Xai
... so WHY do the proponents of hungarian notation want to force this already readily availible information (look up the declartion when necessary - which exactly matches the TRUE compiled code - no chance for version errors) to be viewed and constantly remembered by the programmer.

Sigh, this has been stated over and over again, and I really don''t feel like going through all the reasons again :/.

If some people can''t see, or don''t agree with, the benifits of HN, then don''t use them. I''ve personally worked at places that has and has not used HN and I have found it tremendously easier to work with HN. But maybe that''s just me.


- Houdini