|
Notice how Microsoft has been using i for integers lately (check the latest common controls)? May be you need to update this?
|
|
|
|
|
Keep in mind there are good reasons NOT to use hungarian notation.
1) Hungarian notation was invented a LONG time ago for people that didn't have the great IDEs and compilers we have today. I doubt it would come into use now. Many people who think it's a bad idea - including authors of recent books by Microsoft Press (also Microsoft employees).
2) Some times it's better not to include type information in your names. If the type changes, the names get misleading. I'd much rather have no type information than WRONG type information. Consider:
LPCTSTR - the "L" stands for "long" as in long pointer - But there are no long pointers anymore!
WPARAM - has changed size, but the name is still old.
If you name your variables like this, you'll just end up in the same trap.
3) "n" is for integer - but it doesn't tell you if "short" or "long", so it's not much use. This is especially important, because integers are used so much.
4) Read the original article on hungarian notation:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp
The example code that comes with the article is below. Look at the code and then ask yourself "is the person who wrote this un-readable mess, really someone I should be taking advice from ?"
1 #include “sy.h”
2 extern int *rgwDic;
3 extern int bsyMac;
4 struct SY *PsySz(char sz[])
6 {
7 char *pch;
8 int cch;
9 struct SY *psy, *PsyCreate();
10 int *pbsy;
11 int cwSz;
12 unsigned wHash=0;
13 pch=sz;
14 while (*pch!=0
15 wHash=(wHash<>11+*pch++;
16 cch=pch-sz;
17 pbsy=&rgbsyHash[(wHash&077777)%cwHash];
18 for (; *pbsy!=0; pbsy = &psy->bsyNext)
19 {
20 char *szSy;
21 szSy= (psy=(struct SY*)&rgwDic[*pbsy])->sz;
22 pch=sz;
23 while (*pch==*szSy++)
24 {
25 if (*pch++==0)
26 return (psy);
27 }
28 }
29 cwSz=0;
30 if (cch>=2)
31 cwSz=(cch-2/sizeof(int)+1;
32 *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic;
33 Zero((int *)psy,cwSY);
34 bltbyte(sz, psy->sz, cch+1);
35 return(psy);
36 }
|
|
|
|
|
Hi Warren
I didnt read the article.
But I just read your post.
It's a very well written post Warren.
Thanks,
Nish
p.s. Now I guess I need not feel so guilty and bad about not using proper naming systems 
I am the Keyboard Smasher
|
|
|
|
|
Thank you, Nish.
After going off on my rant about hungarian notation, I would like to add that I think some parts of the article are worth using. For example, I think the "m_" for member variables and "C" in front of class names are good ideas. My real complaint is with adding type information into variable names - that's a bad idea.
Warren
|
|
|
|
|
Yes scope-specific Hungarian, mainly for member variables/fields aids readability.
Kevin
|
|
|
|
|
Ah.. I despise "C" in front of class names. This is horrible. If I created a parser class, it would be called Parser, not CParser. WTF is a CParser, I don't know, but I do know what a Parser is. Capitalizing class names is the only good convention when naming classes. How could anyone not know it's a class? Honestly?
Sorry if I seem aggressive, I'm just having the longest and most boring day in the history of the world.
Jason Gerard
|
|
|
|
|
I agree but the problem is that things like the ClassWizard encourage you to put a C in front of your classes.
The convention I've followed is to put the "C" in front of classes which use a MFC, after all the "C" convention was originated by Microsoft. Classes which must work in multi-platform code do not have a C in front of them.
Regards,
Alvaro
Always do right. This will gratify some people, and astonish the rest. - Mark Twain
|
|
|
|
|
FWIW, Borland used a "T" has the first letter of all of their OWL classes and many others.
|
|
|
|
|
That code would be unreadable without HN.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Tim Smith wrote:
That code would be unreadable without HN.
That code is unreadable. period.
17 pbsy=&rgbsyHash[(wHash&077777)%cwHash]; 
Warren
|
|
|
|
|
1. Many people think it is a good thing including people who currently write books and work for MS.
2. If you change the type of the variable, change the notation. But to your point, I would rather have at least a hint as to what the variable is instead of none.
3. "George" doesn't tell you a damn thing about the variable "George". At least "nGeorge" gives you a hint.
Ultimately, HN is more about religion than any real proof it is good or bad. I have yet to see any evidence either way.
If you like it, use it. If not, don't.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Tim Smith wrote:
Ultimately, HN is more about religion than any real proof it is good or bad.
I agree - it shouldn't be a religion, one way or the other. I just got the impression when I started programming (from all of the books that I read) that HN was the "right" way to do Windows programming.
I wasn't particularly trying to slam HN, I just want other readers to realize that some people use it, and some people don't.
Warren
|
|
|
|
|
I wasn't particularly trying to slam HN, I just want other readers to realize that some people use it, and some people don't.
I can deal with that.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
In some defence of hungarian notation. I use a variant of it myself, so in reply to your points:
Warren Stevens wrote:
Hungarian notation was invented a LONG time ago for people that didn't have the great IDEs and compilers we have today
So was C/C++ (in the scheme of things), Just because something is old doens't mean its dead in the water.
Warren Stevens wrote:
Some times it's better not to include type information in your names. If the type changes, the names get misleading
When this happens, I use find and replace, that what great IDE's are for isn't it?
Warren Stevens wrote:
LPCTSTR - the "L" stands for "long" as in long pointer - But there are no long pointers anymore!
WPARAM - has changed size, but the name is still old.
OK, theres not much I can say about these, they are a carry over from 16-bit windows, and I think M$ would have done away with them if they could.
Warren Stevens wrote:
If you name your variables like this, you'll just end up in the same trap.
Once again, I think Find/Replace can come to the rescue.
I do beleive I read the orignal artical a long time ago. The code you quote is a bad example of how not to write code I think.
Hungarian notation can be a good thing. I think it just comes down to personal preference. Like I said earlier I use a variant of it, but its not a religion.
Roger Allen
Sonork 100.10016
If I'm not breathing, I'm either dead or holding my breath.
A fool jabbers, while a wise man listens. But is he so wise to listen to the fool?
|
|
|
|
|
Roger Allen wrote:
I use find and replace
Find/Replace only works on a small scale, which is why LPCTSTR is going to have an L forever. Once you have shared your code, it's too late to do a find/replace. Consider:
1) We have a lot of code at work shared between multiple projects. For the projects we're not presently working on, we can't just go in and Find/Replace on the shared code (without having to do a re-testing on ALL of the projects).
2) Anything you post on CodeProject. If someone does some modifications, and they get a new version of your code (and they want to insert their little modification) they will have to do the search and replace as well.
Roger Allen wrote:
Like I said earlier I use a variant of it, but its not a religion.
I agree - it shouldn't be a religion, one way or the other. I just got the impression when I started programming (from all of the books that I read) that HN was the "right" way to do Windows programming. I just want other readers to realize that some people use it, and some people don't.
|
|
|
|
|
Warren Stevens wrote:
1) We have a lot of code at work shared between multiple projects. For the projects we're not presently working on, we can't just go in and Find/Replace on the shared code (without having to do a re-testing on ALL of the projects).
Wait, this is insane. You'd happily change the type of a variable, in code that is used in all multiple projects, without testing the projects? Yet you won't do a global search and replace in the same circumstances?
You completely miss the point of the S&R operaation. It has to be done manually.. that is, stopping at each instance and examining the code to make sure there are no problems. then of course it does need to be teted.. but the code examination will catch the bulk of the problems.
|
|
|
|
|
Jim A. Johnson wrote:
Wait, this is insane. You'd happily change the type of a variable, in code that is used in all multiple projects, without testing the projects?
No, I agree, that would be quite insane 
Changing the type should probably require MORE testing than a change of name.
My point was just that when you have a lot of linked source code, a single name change can turn into tons of work. If that name change could be avoided (by not having the type imbeded in the name), then you might be able to save yourself some work.
|
|
|
|
|
Although not perfect there is a great advantage in hungarian notation it is widely spread and understood. When you read MS code you immediately locate the pointers, the members,... the variables what they are, what they state for. I always find MS codes easy to read, all is so obvious.
I supposed you already tried to decrypt somebody's else code - I mean rid of Hungarian notation - was it better ? I can also give you really rubish code examples, worse than the above - I guarantee.
I rather see the hungarian notation as a global rule you're not mandatory to apply stricly, as I do, as you probably do, but the spirit of hungarian notation is that the developper community share the same marks and that is good.
Yarp
|
|
|
|
|
Kindly disagree!
There are many places where Hungarian Notation is valid and quite honestly, I would not want to read a piece of code nor work with a developer who doesn't conform to some sort of Hungarian Notation. Your examples are quite extreme and is not the norm for using Hungarian notation. Every developing group adds/removes from what some perceive as standard Hungarian notation, but it sure helps in understanding the implemented logic.
Warren Stevens wrote:
Some times it's better not to include type information in your names. If the type changes, the names get misleading. I'd much rather have no type information than WRONG type information.
If the type changes, then this makes good reason to change the variable name.
|
|
|
|
|
Change the variable name???
If it's a member of a structure that is used in a large number of modules, this becomes an enormous search-and-replace task, and you run the risk that someone may have used the same member name in a different structure. So globally replacing ".usCount" with ".ulCount" would cause serious problems if a second structure with a ".usCount" member were, for example, being written to or read from a file or pipe interfacing to another system.
Also, if code is being properly maintained in a source control system, checking out and in all the modules can consume
hours of precious developer time.
And what is gained by this? Visual Studio now will tell you the type of any variable or structure member you hold the cursor over. If you use a lint tool -- or even just a good compiler with proper warnings turned on -- you'll be warned of hazardous assignment type coercions. These are exactly the kinds of things that computers are supposed to do for us.
Except for an initial "p" or "pp" to indicate pointers and pointers to pointers, I see no advantage.
Rgds
|
|
|
|
|
Warren Stevens wrote:
1) Hungarian notation was invented a LONG time ago for people that didn't have the great IDEs and compilers we have today. I doubt it would come into use now. Many people who think it's a bad idea - including authors of recent books by Microsoft Press (also Microsoft employees).
This proves only that people at M$ are allowed to think. Everyone is entitled to their opinion, but I don't see how the IDE makes any difference. VC does not tell you the type of a variable without VA.
Warren Stevens wrote:
Some times it's better not to include type information in your names. If the type changes, the names get misleading. I'd much rather have no type information than WRONG type information. Consider:
The key word here is design. Yes, WPARAM is an obvious example, but I doubt I'll be writing any code that crosses the boundaries WPARAM has.
Warren Stevens wrote:
If you name your variables like this, you'll just end up in the same trap.
I've once or twice needed to do a find and replace, but it's pretty rare. That's largely because I use n for all numbers now.
Warren Stevens wrote:
3) "n" is for integer - but it doesn't tell you if "short" or "long", so it's not much use. This is especially important, because integers are used so much.
This point is idiotic - how does that make it worse than no info on the type at all ? Some people go to greater lengths than 'n' anyhow - the point you are making is moving in the wrong firection from what you're trying to say.
Warren Stevens wrote:
The example code that comes with the article is below. Look at the code and then ask yourself "is the person who wrote this un-readable mess, really someone I should be taking advice from ?"
I'm sorry, but I don't regard this as religious war. I do find HN useful, if you don't, don't use it. You won't get a job anywhere near where I work though. Upholding a standard is more important than what that standard is, and HN is very useful in my experience.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
Christian Graus wrote:
I do find HN useful, if you don't, don't use it. You won't get a job anywhere near where I work though.
Somehow, i think this is true in many places. For myself, i never used HN until i decided to get a job programming. Now i must use it as it is part of the coding standards for the group i'm in.
To a point, i think it is useful, as it enforces some minimum standard (scope, pointer) for descriptive variable names. In the end though, a lazy programmer without HN will have meaningless variable names. A lazy programmer with HN will have meaningless variable names with (possibly correct) HN prefixes. Bad code is still bad code no matter how many coding standards are set down 
Sometimes i only remember, The days when i was young
Nowadays no one remembers when they were young and stupid... ADEMA, The Way You Like It
|
|
|
|
|
1) Christian Graus wrote:
Everyone is entitled to their opinion, but I don't see how the IDE makes any difference.
I was including VA (and any other small add-on) as part of my definition of "IDE". What I meant is that there a lot of tools available that make this whole argument moot.
2) Jim Meek makes some good points (see another thread)
3) Christian Graus wrote:
I'm sorry, but I don't regard this as religious war...You won't get a job anywhere near where I work though...
If that's not being religious about HN, what is ?!?
|
|
|
|
|
Warren Stevens wrote:
3) Christian Graus wrote:
I'm sorry, but I don't regard this as religious war...You won't get a job anywhere near where I work though...
If that's not being religious about HN, what is ?!?
It's a statement of fact - having a convention is more important than what that convention is. Every place I have worked, the convetion has been HN.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
- having a convention is more important than what that convention is.
While i'm not going to weigh in on this pointless hungarian discussion...
I must point out that that statement is a common logical fallacy.
your argument comes down to something like this:
Conventions are needed
HN is a convention
therefore
HN is needed
i'm sure it can be made obvious that this is wrong simply by:
Food is needed
Raw Monkey Brains is food
therefore
Raw Monkey Brains are needed
The anti-hungarians aren't saying that you don't need food... they are stating that Raw Monkey Brains isn't the best choice. 
As for the rest of the group using HN... I'm sure most of us has had a mother who told us the old "if your friends jumped off the Brooklyn Bridge" story...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
