View Full Version : Hungarian Notation

12-19-2001, 10:48 PM
Good or bad?

12-19-2001, 11:13 PM
int inum;
double dcalc;
float fmoney;

Well, it's good in the sense that you can tell what type you are dealing with without having to go back to the point where the variable was defined, but with a good editor you just have to put your cursor on top of the variable and it will tell you all about it, so it's not necessary to use hungarian notation.

12-19-2001, 11:24 PM
I use it only in WIN32 API.

I only started using it after I spent two days looking for an error. I found I had mixed a memory handle and an array variable name. If I had been using the notation it would not have happened.

12-20-2001, 12:41 AM
i've never used it... not since my projects don't get that large... it's rather that the scope of my code blocks never get that large... and isn't compact coding and blackbox functional units _the_ principle of C/++ programming? that's what i've always done... i probably got this idea from Herbert Schildt and 1984, but enough about that... :)

12-20-2001, 12:50 AM
-sigh-, I can't believe we're talking about this again...

I love Hungarian notation ONLY when it's required, such as team projects or large programs, but if you're making a quick calculator, I don't think you should bother at all, specially when you're making an integer called i, you should name it Ii, and this could lead to serious confusions, specially because you might confuse the capital letter and type "iI", or "II" or maybe even "2" when you're really confused (please don't make me explaint that joke for you)


12-20-2001, 01:16 AM
It was required in my first C course....Just as a learning/debugging tool I suppose. It was never really that big of a deal or confusing to me. I was taught to never use i as an integer outside of a for loop. It's good practice to use more descriptive variable names anyways, and this can be a good way to help.

12-20-2001, 04:14 AM
It's good, it's hungarian ;).

Didn't like it when had to deal with it for the first time, but now I use it always. If you're working in a team, on a bigger project, it's inevitable to use it. Especially in 4th generation programming languages.

12-20-2001, 04:27 AM
Don't use it, never have, regulaly work in a team, often on multi-million line code jobs. If you're a professional and your IDE can't tell you what type your variable is, then you're using the wrong tools.

12-20-2001, 04:29 AM
Hehe, Adrianxw, what a deją-vu feeling ;)

We had that discussion a few months ago.

12-20-2001, 09:30 AM
>If you're a professional and your IDE can't tell you what type your variable is, then you're using the wrong tools.

hey now, i agree with that! reduce the scope, and make all your code more block oriented... but i'm still scratching my head over the multiline varible declarations adrian... thanks just the same...

seems to me that if you've got bulletproof code, it becomes as reliable [and hopefully as documented] as any of the standard library functions... then you take it for granted... [which is good]... how does anything besides descriptive data handles improve bulletproof code? :)

12-20-2001, 11:43 AM
I dont like some of the microsoft standards for certain things 'lpsz' for instance, but i do try to prefix my variable in larger projects. It really can help me find problems sometimes, but there is no reason to prefix every variable in every function one writes.

12-20-2001, 12:55 PM

>>> Hehe, Adrianxw, what a deją-vu feeling

Yup, seem to recall that too.


>>> i'm still scratching my head over the multiline varible declarations adrian

What's the problem?

int *a,b; // Not a problem but a potential problem

int *a;
int b;

No problem. One line, one declaration.

12-20-2001, 04:31 PM
See, but I don't agree UNLESS you're using pointers...or arrays (I just don't like the look of "arr1[20],arr2[30],arr3[40]"). like to me, something like

int a, b, c;

is just fine. Wastes a little less space and generally easier to type. but if you've got

char *a, *b, c;

that's be much better as

char *a;
char *b;
char c;

but wasn't there a thread for this SOMEwhere?

12-20-2001, 06:29 PM
yeah, what i'm saying is a good programmer would know the conventions for single line declarations of several variables, so why not use them? the only potential problem i can see is the one you pointed out, where pointer signification is not distributed... but that's it... so... why? you'd know of it, y'know what i'm saying?

12-20-2001, 07:58 PM
I dont bother using it with variables of local scope unless they are pointers. Pointers are always pPointer. It just pakes sense. Globals (if for some strange reason i have any) are always g_pPointer or g_iInteger or whatever. Theres rarely a point in notarizing locals.

char *a, *b, c;

that's be much better as

char *a;
char *b;
char c;
Very much agreed. Alternatly i do this:

*a, //with the added bonus
*b, //that you can describe each
c; //variables use after its definition
Although i would never be caught dead using variables with names like a, b, and c but this is of course an example.

12-20-2001, 08:14 PM
hmm....never really thought about something like

char *a,

I think I'll steal that method from you, it's niiicccee :)

I really don't like hungarian notation though...it's...ugly! I always try to make my source pretty ;)...but still. I'd never be caught dead writing code like:

unsigned int *g_puiVariable;

I'm much happier with

unsinged int *Variable;

and running my mouse over the variable to see what type it was if I ever needed to...

12-20-2001, 09:18 PM
For short program, I don't use it. But for big program... Hungarian notation!!

12-20-2001, 09:28 PM
I don't like it, because if I ever want to typecast, I have to screw around with the variable name, and I might have to change the whole program. That would be unfortunate.

12-20-2001, 09:29 PM
Errr, not typecast. But, if I was using an int, and I needed to change it to a long because the number needed a decimal point, then it would be kind of dumb.

12-21-2001, 12:31 PM
its rotten

millions of lines of the linux kernel dont use hungarian (or for that matter any) notation

and yet its more stable than win which does

i guess its better to write ample comments in your code rather than resorting to

for(int Ii = 0; Ii ...etc

12-21-2001, 08:45 PM
i guess its better to write ample comments
The one good thing to be said for hungarian notation is that you're never going to do this:

iNum = 298500;

or this

ulNum = -298500;

Not that its very likely anyhow, but...

I think I'll steal that method from you, it's niiicccee
Why thank you. Glad to have contributed something. :)

04-17-2002, 04:57 AM
Poll closed. Please don't vote on polls older than 3 months, it's like post-bumping.