When working on large team project, code standards are vital. HN gives some guidelines for coding standards. Many projects find it better to only adopt some of them.

Our team uses m_ for all member variables, but that's all that's required. Personally, I use a p for all pointers, and I find the n and c are very helpful when talking about quantities. n = index and c = count. This is really nice when doing graphics calculations--you can readily tell which ints are quantities and which are indices.

Edited by - Stoffel on December 12, 2000 2:34:56 PM

Stoffel, I go back and forth about things you post (meaning I have noticed that I either wholeheartadly agree with your ideals or vice-versa - probably because you and me are both very high idealed), and in this case I like your post a lot. But it combined with Houdini''s last post make me want to respond.

I don''t think a lot of people appreciate a distinction I''m making. Houdini said m_, g_ are hungarian notation, at least the way he reads it ... well fine, I disagree, but this is not a discussion about the details of the system, it is a discussion about good and bad programming practice.

What I am saying is that the Hungarian Notation as practiced by Microsoft and widely copied, is primarily the practice of embedding concrete type information in a variable name. THIS is what I disagree with. Use "find" or "find in files" when you do not know the type of a variable, but when you do not know and do not NEED to know ... then you are correctly benifiting from abstraction.

The m_, g_, n, c etc ... are NOT the same as embedding information about the variable being and int or a pointer. IN the case of m_, g_ you are embedding scope information ... this has it''s uses, which I admitted - and if you want to call it hungarian notation - FINE - but I''m trying to seperate it to let people use such things without bringing in the aspects of HN that I find flawed. In the case of n, c etc ... you are embedding INTENT/USAGE .. these are the highest form of naming conventions, they are proper and helpful (I do not use these 2 in particular, but the concept remains with the way I name char* variables containing generic data (buffers) differently than char* pointers containing null terminated text(strings)).

See, my naming convention / programming style is VERY similar the the microsoft style. I use consistent capitolization rules for different syntactic elements. I use consistent spacing / commenting / arangement rules for all of my code. I comment significantly, but I do not comment ANYTHING that is 95% as easy to read in the code as the comment - I ADD information with my comments, and that is the same idea with my names - ADD information that is not obvious to the reader.

NOW .. time to address some issues houdini brought up. I do not know how to post quote blocks, so I''ll just go paragraph-by=paragraph.

P1) Addressed above

P2) I was not saying don''t use the system because people could mess up. I was saying I have not seen proper notation to distinguish things like class members, and if the system covers the general cases, but not some other fairly common ones, then it makes the users work harder, due to the inconsistency.
Maybe your system correctly distinguishes class variables, but microsoft''s system simply labels them m_ like everything else.

P3) I left of the inner type, because it wasn''t being discussed in that example ... for the sake of argument it didn''t matter if it was pointer to int or pointer to char ... I was only discussing the apllication of HN to pointers ... not the fact that of course you always combine all aspects of your notation - yielding perfectly find variables like this: m_ppdwGameScores.

P4) I have never worked for a large company ... but I consulted on a large project (The project was so big I never even had a copy of all of the files, but in just the module I looked over I worked in 4 files (30+ printed pages) which were nested in a module of about 130 files - the project used HN, but it did NO GOOD ... because the Data Format Description was 450 pages long, and there were over 200 different important structs - over 50 of which I had to use - you try and remember the 2-3 letter codes for those - it is my opinion that longer, descriptive, variable names would have been less confusing and more usefull than HN). As for my own projects, my last project was 3 programmers for 18 months ... generating nearly 200 C++ source files which would not fit in a 1" binder when printed ... does this qualify as large enough to require a good system to keep strait ... I personally worked in about 12 seperate modules out of 27 ... and had to use all of them. And also, why do people always say "I assume you''ve never worked on a large project ... blah blah. Don''t you realize there are great and terrible coders and pieces of code everywhere ... from the 1-3 men teams to the large corperate software factories. I know work at a company with 9 programmers, 6 of which are on the main team (myself as well), but there is significant disparity in the quality of code produced and documentation provided.

P5) Not much to say ... I have read nearly the entire 4 page post ... I know some people opinions .. but some (on both sides) are so poorly thought out that I figured you might want to simply cut and paste the strongest of your ideas.

As for the ''if some can''t see'' statement ... of course that''s true ... and this is a friendly discussion ... but if you could ask my coworkers you would find that I have opinions about this stuff not to convince people I''m right ... or convert the world ... but because I actually do care about things like the quality of code developed and the knowledge / beliefs people have about such things ... just as there will always be partisan politics .. there will always be argument .. but I am not after a victory .. I am after knowledge.

quote: Original post by Xai

Houdini said m_, g_ are hungarian notation, at least the way he reads it ... well fine, I disagree, but this is not a discussion about the details of the system, it is a discussion about good and bad programming practice.

I''m not saying that m_, g_ are Hungarian Notation, but rather Hungarian Notation includes them. I''ve yet to see a Hungarian Table without these prefixes listed. But you are right, this isn''t a discussion of whether m_ and g_ are part of Hungarian Notation so let''s move on to more important stuff.

quote: Original post by Xai

Use "find" or "find in files" when you do not know the type of a variable

Using "find in files" can be very time consuming, depending on the size of your projects and your computer speed. With my 700Mhz pc at work it takes well over a minute to finish a "find in files". Also, you could easily end up with hundreds of matches where your variable is being used in code, and only one out of those hundered will actually be your variable declaration, so you''ll have to search through that as well. Not a big deal for small projects, but a pain in the ass for large ones.

quote: Original post by Xai

but when you do not know and do not NEED to know ... then you are correctly benifiting from abstraction.

The m_, g_, n, c etc ... are NOT the same as embedding information about the variable being and int or a pointer. IN the case of m_, g_ you are embedding scope information ... this has it''s uses, which I admitted - and if you want to call it hungarian notation - FINE - but I''m trying to seperate it to let people use such things without bringing in the aspects of HN that I find flawed.

You''ve brought up a point that many other have as well: abstraction. And believe me, I do see your point. When someone else brought that up it caused me to re-think my decision to use Hungarian Notation, but in the end I decided to stick with it. Here''s why:

Abstraction is used to hide the information about an object, which is a Good Thing in programming. It''s something that C++ is built around. However, in your case abstraction is being used at too low a level. If you were going to have public member variables and global variables, then I can see how abstraction in variable naming could be a Good Thing. However, both public and global variables are a big no-no in programming and should be avoided at all costs, so I''m going to leave these out of the discussion.

Instead, we are dealing with a variable being used inside the class (or module) which declared it. The class itself already KNOWS about the type since it had to delcare it, which breaks your abstraction. You also write code that specifically pertains to that type. Example:

int TempPlayerID = PlayerID;

This line breaks your abstraction because you are hard-coding that PlayerID will always be an int. Since the class is going to use this variable at the lowest level, abstraction here doesn''t and shouldn''t exist. The variable is still being hidden from the rest of the program, so you still have that higher level of abstraction.

quote: Original post by Xai

I was not saying don''t use the system because people could mess up. I was saying I have not seen proper notation to distinguish things like class members, and if the system covers the general cases, but not some other fairly common ones, then it makes the users work harder, due to the inconsistency.
Maybe your system correctly distinguishes class variables, but microsoft''s system simply labels them m_ like everything else.

True this is a little trickier, but I''m willing to bet you already distunquish the class type in your variable names.

Let''s say you have a structure called Coordinate that contains X and Y integer variables. If you want to store the middle coordinate of a rectangle, how do you name your variable? Prolly something like this:

Coordinate MiddleCoor;

But putting Coor in the name would break the abstraction you talked about earlier, because you include the variable type in the name. Same goes if you wanted to hold the current mouse event you would name it MouseEvent CurrentMouseEvent; or something similar.

Now this brings up the interesting fact that you are now MIXING naming techniques. You include the data types in user-defined types, but exclude them with standard data types. I''m not even going to go into how much of a bad of an idea it is to mix naming conventions...

Of course, the reason they say to exclude the type for variables of standard types is because you should always know the type from the name. But this simply isn''t true. I''m now going to paraphrase something I said in another post.

Let''s say you are brought into a company and they want you to make bug fixes to a program you''ve never seen before. Here are some variables you see (these are taken directly from my work program, minus the Hungarian Notation)

ShippingStatus
CustomerNumber

Now tell me what type ShippingStatus is? Is it a integer, string, enum? There is no possible way to know.

Well, at least you know CustomerNumber is a number value, you just don''t know what kind. Right? Wrong. CustomerNumber is an alpha-numeric value, in other words it''s a string. It''s not a bad variable name because it IS a Customer Number. SerialNumber is another great example except everyone already knows it would be a string.

quote: Original post by Xai

I have never worked for a large company ... but I consulted on a large project (The project was so big I never even had a copy of all of the files, but in just the module I looked over I worked in 4 files (30+ printed pages) which were nested in a module of about 130 files - the project used HN, but it did NO GOOD ... because the Data Format Description was 450 pages long, and there were over 200 different important structs - over 50 of which I had to use - you try and remember the 2-3 letter codes for those - it is my opinion that longer, descriptive, variable names would have been less confusing and more usefull than HN). As for my own projects, my last project was 3 programmers for 18 months ... generating nearly 200 C++ source files which would not fit in a 1" binder when printed ... does this qualify as large enough to require a good system to keep strait ... I personally worked in about 12 seperate modules out of 27 ... and had to use all of them.

See my previous reply as to what to do. And remember you don''t HAVE to use abbreviations for user-defined data types. If an abbreviation isn''t obvious, then spell it out:

Coordinate coorMiddle;
Button buttonAudio;

The whole idea of Hungarian Notation is to allow the programmer to know what kind of variable it is. Doesn''t matter if you abbreviate or spell it out, as long as you get the point across.

quote: Original post by Xai

And also, why do people always say "I assume you''ve never worked on a large project ... blah blah. Don''t you realize there are great and terrible coders and pieces of code everywhere ... from the 1-3 men teams to the large corperate software factories. I know work at a company with 9 programmers, 6 of which are on the main team (myself as well), but there is significant disparity in the quality of code produced and documentation provided.

True, and I apologize if I didn''t explain myself clearly. The reason I stated about "large projects that you don''t write" is because in small projects that you write, Hungarian Notation isn''t a must. It becomes more and more important the larger the project gets, especially if you aren''t familiar with the code. I wasn''t trying to say that lone programmers are any worse than ones who work in large companies.


- Houdini