I use a ''lite'' version of this. Scrap the C for classes, but the m_ for members, the sz for strings - etc.

I even use this in scripting, when things are typeless. Mainly because it helps me figure things out.

quote:Original post by Oxyd
Also - if you see

if (time >= 1.0) ...    

then it is clear, that ''time'' is a double.

It''s also clear that the programmer is a novice, given that floating-point values shouldn''t be compared for inequality in any fashion. Use an epsilon instead.

quote:Original post by dmikesell
Was it ever necessary in the first place?

Yes. It''s roots lie in assembly programming, where type doesn''t exist. It was a mnemonic device, if you will, to indicate the usage of variables - not type. That''s where everybody got mixed up, and where it became useless. Type changes over time - see the various obsolete Win32 prefixes, for example - but usage is fairly consistent.

Today, without significant identifier length limitations (some old assembly source files allowed only 16 characters per line), usage can be indicated through intelligent variable naming. With our fancy IDEs today (and if you''re not using an IDE with IntelliSense-type features, you''re a masochistic moron), type information is available on hover. Throw in good comments and other code refactoring practices, such as reasonably-sized code blocks, and Hungarian notation is completely unnecessary.

I''ve been programming for eleven years. I''ve never found it necessary. Caveat emptor.

quote:Original post by paulsdsrubbish
I think some of the posters have been lone-wolves... perhaps never being thrown in to a situation where you take over another engineers code that didn''t bother to comment, document or perhaps have any standards at all. Then you do have the luxury of coding however you like, because you are likely to understand what you did...

Completely orthogonal to the discussion. What is a good idea and what you are required to do at work are mutually exclusive, though occasionally coincident, concepts.

quote:I must say I am suprised about the anti-feeling that''s around to it right now, back in university a few years ago I''m sure it was encouraged by some tutors.

It''s called the Tipping Point. Eventually an idea - good or bad (good: Hungarian Notation is now redundant; bad: "low-carb lifestyle") - gains enough steam that it begins to force the hands of others to some extent, even if they don''t necessarily agree (a morally ambiguous example: women''s low-rise jeans - some like it, some don''t, but it''s hard for women to find stylish jeans with comfortable waistlines).

I think that about covers it.

It''s getting a lot of flack in this thread so I thought I''d offer it a little support. Brace yourselves...

I use Hungarian Notation.

if (time >= 1.0) does not necessarily imply that the variable "time" is a float. Sure, it had ought to be, but for what little trouble it is to type "f" or "d" before the variable name, I think it''s worth it. Though there is effectively no logical difference between

if (iTime >= 1.0)

and

if (fTime >= 1.0)

there are instances when it would be useful to know what each one is...if you''re working with the code and need to fix something. I think we can all imagine a situation in which we might need to know the particular type of "time" (or whatever) before we do something. Even if we can determine the type on the fly, it''s it irreverent?

But hey, with fancy IDEs, good comments, and good memories, maybe it''s not necessary at all. I seem to remember writing BASIC code (on an Apple IIe when I started programming, 13 years old?), I only used variables named with one or two characters, and always I created and used them in alphabetical order.

int A
string B
int C

And I didn''t use comments, subroutines, or really anything other than GOTO. I don''t think I even used "if". What''s the point of complex variable naming when you don''t use "if".

Peace, all.

Personally, I have found that it's more valuable to use variable notation to express the scope of variables rather than their types.

For instance, it is pretty obvious that NumPlayers or PlayerCount is some type of integer, that PlayerName is some type of string, and that IsPlayer is some type of boolean, so hungarian notation IMO becomes redundant if you name your variables descriptively.

I do, however use the following notation:

m - for member variableg - for global variablex - for function parameter - no prefix for local variablesp - for pointersC - for classes 

Take the simple example of an accessor function that sets the value of a class member:

void CSomeClass::SetSomeInt(int xSomeInt){	mSomeInt = xSomeInt;} 

I can immediately tell that I'm setting the object's copy of SomeInt to whatever value was passed in externally without referring to the definitions of mSomeInt and xSomeInt. Notating in this way gives me a hint as to how long those variables will be in memory, and what other code has access to them, without having to go back and look up how they were defined.


[edited by - EvilSteve on June 10, 2004 3:01:39 PM]

Indeed, I agree some small ammount of notation is handy.

I use the prefix of "in" for all incomming function variables, "t" for temp variables within a code block, "m" for member variables and "g" for the exceedinly rare occasions I have globals.

I see no need for pointer identification.