|
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...
|
|
|
|
|
Andy Smith wrote:
Conventions are needed
HN is a convention
therefore
HN is needed
9/10 intelligent people would percieve that is not what I said. What I was saying was that conventions are needed, and I'd rather confrom to HN *if* that is the convention in my workplace, than feel I was doing it better by dissenting. IF a workplace does not use HN, I would not use it alone, for the same reasons.
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
|
|
|
|
|
Conventions are needed
HN is a convention
therefore
HN is needed
Regardz
Colin J Davies
Sonork ID 100.9197:Colin
I think it's interesting that we often qu-ote each other in our sigs and attribute the qu-otes to "The Lounge". --- Daniel Fergusson, "The Lounge"
|
|
|
|
|
Dear Sirs,
I am a programmer from Chile (South America) and I was looking for a real help to name our variables in order to share the code and in order to create applications with teamwork, then I think is very important before start typing the procedures, modules and all that to state a convention for your code even how to write remarks to your code. Also I found some hard to read my own code after few weeks. I started intuitively with a sort of naming convention like ary_DataX() for an array od Data axis X of a graph, but then a tried to found some helpo in the web. And voila, what I found was a group discussing if it is or not a good idea to name your variables like HN convention says.... I think relley doesn't matter. What matter for my is found or discussing how to name or create code in a such way we could share it. I understand if you don't understand something like "nsPgh" or what ever. I really prefer something like "idx_i" for "index i" or aryVarName() for an array instead of "aVarName()".
Then conclusion:
1) Right now I'm reading about Hungarian Convention and other related articles to found an idea and then I will create my own naming convention to share code with my colleages. I hope to do it right or readable for each one of my team. I prefer as many something with sense instead of cryptography.
2) I would like to found a discussion where the people who criticise something not only point about the bad things, also add some commentaries or ideas to be discussed.
Ok fellows go ahead and thank for your words. I will try to thing in a convention name not 100% tied with the HN, but I thing the core of the issue is very interesting. I mean the question:
"How I would structure the naming convention of the code in order to share and understand the code when you are working in a teamwork?"
Saludos and Regards,
Tomás Giacaman
tgiacaman@hotmail.com
|
|
|
|
|
Andy Smith wrote:
Raw Monkey Brains are needed
I love the Raw Monkey Brains analogy. I guess raw is worse than cooked
R.Bischoff
Tengas un buen dia
|
|
|
|
|
My god... That was impressive. I really think you should try to listen people like Tim Smith, Christian Graus, ... Because you really need to understand one thing: Think about it twice before posting such a stupid and useless remark about HN.
1) HN is used as a base for most of the existing programming conventions. It doesn't matter if you use it or not, you have to choose convention before starting any project. Even if you're the only "hardcoder".
2) Well if you don't use a prefix, how do you name your variables ? Let's take a MFC example, you create a CListBox object that will list some Names, you name it ListBoxName or lbName ? It doesn't matter as long as you choose a convention! I prefer lb because it's shorter... But if you choose ListBox well... It's your choice!
3) It totally agree with you that's why I never use s or l, I simply use "n" for all my (n)umbers. But not real numbers :p
4) So you only read that document ? I can give you some good references if you're pleased to listen.
The example code you submitted is the best you could give for us, defenders of the programming conventions . Because it doesn't represent at all what HN is about. No spaces, no tabs, stupid names, pointers, stupid algorithms, C in C++ craps... I told you it's really impressive!
I don't have much time to re-write it correctly (in my opinion) so let's say that you should try to more... careful
Jean-Marc Molina
Email: jmmolina@ifrance.com
Web: http://goa.ifrance.com
|
|
|
|
|
Jean-Marc,
You should really read a message, and try to understand what the person was trying to say, before you reply to it. You should also try not to be so insulting.
Jean-Marc Molina wrote:
Because it doesn't represent at all what HN is about. No spaces, no tabs, stupid names, pointers, stupid algorithms
THAT was my point exactly. The example code was quite unreadable, and the person who wrote the code
a) thought that the code was not only okay, but good enough to use as an example.
b) invented HN
So I said:
Warren Stevens wrote:
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 know there a bazzillion articles on HN, I was just picking one (that the inventor of HN wrote) to show that he might not be the best person to take advice from.
As you said:
let's say that you should try to be more... careful
|
|
|
|
|
If you condemn HN as obsolete due to modern compilers, you should consider that HN helps the programmer read the code, not the compiler.
I personally use a variant with all types capitlized variables miniscule and additional semantic prefixes like Lim, Max, Min.
This way I can use the same name for type/class and variable; e.g:
Color color;
The somewaht formal naming procedure actually simplifies the task for me, because in 80% of the cases I immediatly know how a new variable should read; and 100 lines down I can reference the variable wichout looking up again.
Another thought is: whenever too many prefixes add up and hte according name grows ugly I automatically feel an urge to reconsider whether this complicated access is really unavoidable. And simplifying things is usuallly good programming practice.
|
|
|
|
|
Has this question been posted as a poll before? If not I am seeing a winner here!
|
|
|
|
|
It's nice to see somethng like this; someone advocating Hungarian without going into the full "goulash" that's created when everything has its own prefix.
Here are some suggestions of mine:
- s_ for a static scoped variable.
- str for a string (from MFC)
- u for unsigned integer
- i for signed integer
- s for short, signed integer
- Use all uppercase for constants (something my Mac programmer colleagues seem to have a constant problem (kProblem) with :')
- Most important: avoid the temptation to give every data type its own prefix! When this happens the code starts to become incomprehensible because there are too many "standard prefixs" to keep track of.
|
|
|
|
|
Jim A. Johnson wrote:
- u for unsigned integer
- i for signed integer
- s for short, signed integer
- Most important: avoid the temptation to give every data type its own prefix! When this happens the code starts to become incomprehensible because there are too many "standard prefixs" to keep track of.
Is this meant to be ironic ?
FWIW, I use n for any number, so that if I need to change the type, I don't need to change it in a bajillion places.
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
|
|
|
|
|
I also use n for integer numbers. Any more and it just becomes a nightmare. I used to use l for longs and i for ints but it didn't make the code more readable.
Michael
|
|
|
|
|
I used to use b for bugs but then I started coding in VC++ and bugs are a thing of the past.
|
|
|
|
|
cheers,
Chris Maunder
|
|
|
|
|
Christian Graus wrote:
- Most important: avoid the temptation to give every data type its own prefix! When this happens the code starts to become incomprehensible because there are too many "standard prefixs" to keep track of.
Is this meant to be ironic ?
Not at all. I've seen several projects where every class has its own little prefix.. some from MS. Can't think of examples now, but in the MS case, they mostly have to do with handles: hwndMain, hbmpSomething, hpalSomething, rather than hMainWnd (or hMainWindow), hSomeBitmap, hSomePalette.
Christian Graus wrote:
FWIW, I use n for any number, so that if I need to change the type, I don't need to change it in a bajillion places.
That's where it's confusing. There are too many types of numbers - integers, floats, and bytes are all numbers. I use types in my notation specifically so that I can watch for trouble like:
cSomething = bySomething; // Why am I stuffing a byte into a char?
Kind of a contrived example, of course.. the compiler will catch the nastiest ones (comparison of signed vs. unsigned); but knowing the sizes of things halps me avoid problems.
|
|
|
|
|
At my office, we've implemented nearly identical standards.
|
|
|
|
|
You have writte the following:
Bitmap | IDB_ | IDC_ARROW
I think that should be IDB_ARROW
And maybe another one:
Windows message | Msg | msgCut
Should msg start with a capital letter or not?
And one in your last sentence
Free free to ...
I think it should be "Feel free to ..."
Bye,
Gertschi
|
|
|
|
|
i'd like to say you'd found my deliberate istakes
but as they were not deliberate...;)
i'll fix those righ away
thanks
Bryce
|
|
|
|
|
Great to have a list like that.
Does anybody have something similar for the coding styles for C# and other .NET languages.
Michael
|
|
|
|
|
Microsoft covers it nicely themselves, see the Design Guidelines for Class Library Developers. This document covers names for public things, amongst many other things, but when considering local variable names, note particularly the section on parameter names. In short, things have changed a lot - camel casing and no hungarian notation.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
Arghh, 10 year of coding style down the drain
Thanks for the link.
Michael
|
|
|
|
|