|
Well, I've tried both. I switch back and forth between various types. I tend to go with hungarian notation when I do Windows programming, because it's kind of standard there. When I do UNIX programming I use the small letters and underscore. When I do Java (when I have to that is), I use Java naming. When I do C#, I do hungarian.. mostly because it just feels right.
Also, when I do STL-like code, I go with "UNIX"-naming, because that's how STL is written. Thus my code will look better if it matches the looks of STL.
I really don't have a problem with any of the types. I just think it looks silly if I'm using one convention in an environment which uses another. I just go with the flow.
Why being so damn hung up on notation anyway? Hungarian notation isn't hard to read. Just ignore the prefix  It may be a bit more to type, but I'll gladly type the extra characters to make my code looking not too alien in the environment where it is running.
--
Berlin - Die heimliche schwedishe Hauptstadt.
IKEA
Wohnst du nach oder lebst du schon?
|
|
|
|
|
|
You are correct
To all you vader haters out there
|
|
|
|
|
That flash flick is soo damn funny! I think I'll watch it again.
--
Berlin - Die heimliche schwedishe Hauptstadt.
IKEA
Wohnst du nach oder lebst du schon?
|
|
|
|
|
I had to vote "Other" since I use a mix of conventions for different purposes... some were listed, some were not.
ALL_CAPS_WITH_UNDERSCORES: constants/defines
camelNotation: Local variables. Also used for private member functions.
mMemberPrefix: member variables of classes
PascalNotation: Function and class names, and enums
.. and occasionally some others come up as the need arises.
Almost never use Hungarian or any kind of type prefixes. I sometimes use "p" for pointer, but I don't really know why. It doesn't seem to help anything, but yet I feel compelled to do it. About the only time I use any kind of type prefix is when I have code that converts stuff between two different types. Then it makes sense to have, say, a string and an int of the same name, so I need to tell them apart.
I didn't use to prefix member variables with an "m", but out of a compromise for our coding standards, I have been doing so. It has mixed results... it is kind of a pain, but at least it solves the problem of member functions that set variables - you no longer have a name clash.
No single raindrop believes that it is responsible for the flood.
|
|
|
|
|
Navin wrote:
ALL_CAPS_WITH_UNDERSCORES: constants/defines
camelNotation: Local variables. Also used for private member functions.
mMemberPrefix: member variables of classes
PascalNotation: Function and class names, and enums
Looks fine as mine... Where r u from Navin?
I was born intelligent
Education ruined me!.
|
|
|
|
|
|
Philosophically, we use the Pascal convention but with a small selection of acceptable prefixes which effectively convert us to Camel case.
We use mostly English prefixes such as "the" (where broadly speaking we know what's in the variable) and "a" (where we don't, because it's local to a loop of some sort). Other acceptable prefixes are "in" and "out".
I think I would prefer that we use "the" only for member variables and don't use a prefix for local variables, unless it's set in a loop and therefore warrants using "a". I feel that "the" is rather over-used in our code - but otherwise, it seems to work fairly well and generally improves code readability.
Gavin Greig
"Haw, you're no deid," girned Charon. "Get aff ma boat or ah'll report ye."
Matthew Fitt - The Hoose O Haivers: The Twelve Trauchles O Heracles.
|
|
|
|
|
|
|
|
That must be one of the most confusing and awfully written articles I have ever read.
If it's purpose is to point out that Hungarian notation is confusing and useless, then it should heal thyself, physician.
(I realise it was trying to be a clever dick, but it was too clever for it's own clogs IMO)
regards,
Paul Watson
Bluegrass
South Africa
Brian Welsch wrote:
"blah blah blah, maybe a potato?" while translating my Afrikaans.
Crikey! ain't life grand?
|
|
|
|
|
I liked that quotation from the previous link:
"and of no relevance at all in a type-safe object-oriented language like C++."
(Talking about the hungarian notation)
|
|
|
|
|
This from the people who gave us the export keyword. "Mom, can we add export to the language, Billy next door has export. The kids at school make fun of me for not having export."
I actually have a LOT of respect for Sutter (sp?). I don't agree with a lot of the stuff he says but he does his research and has no problem telling people when he is wrong (i.e. the export keyword).
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Michael Dunn wrote:
when used properly, they make code easier to read
But even that simple statement is debatable. It depends what you mean by "properly": strictly (always) or when relevant (only when confusion may arise)?
|
|
|
|
|
I couldn't agree more. Hungarian notation has helped our shop weed out logical errors such as:
int cycles = 0;
...
if (cycles)
...;
which are easy to find when we use Hungarian notation:
int nCycles = 0;
...
if (nCycles)
...;
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
The problem here is a bad name for cycles. In my workplace, plural nouns must denote containers/arrays, so it would mean that cycles is a vector of cycle objects. I would call it cycleCount, and then you don't need Hungarian, and it is more descriptive.
|
|
|
|
|
|
Totally agree. If people would have appropriate names for variables, there is little to no need for hungarian notation.
what does "strFirstName" buy me that
"FirstName" does not.
John K.
|
|
|
|
|
Actually
strFirstName tells me its a string objects
whereas
szFirstName tells me its a char array.
I know its small, but these little things help.
Also, FirstName is going to be a string object or char array, fine
but consistancy in convention is more important than the convention itself.
So if you are going to use str..., sz... n... d... whatever, then you should use it everywhere, even in FirstName.
Jules
|
|
|
|
|
Julien wrote:
Actually
strFirstName tells me its a string objects
whereas
szFirstName tells me its a char array.
I know its small, but these little things help.
Have you ever taken the time to hover you mouse over a variable in the IDE, I think the type is very clear...
I code to make money not to attain some form of higher enlightenment, and use every tool made available to me to make this process easier.
|
|
|
|
|
Hey J.B
I did say 'small'.
I don't know why you think I'm some code-monk looking for enlightenment. I think you'll find quite a few of the developers here code 'to make money', perhaps we should have a poll for this?
I use mouse over function also for more complex types that I don't have control over. I was just saying I think it helps.
Julien.
|
|
|
|
|
sounds like a good poll.
I come across many different standards for coding conventions, and sometimes absolutely none or several in one project (just look at some of my code on a bad day  ) So far the best as far as consistency and implementation came from a Xtreme programming shop (not that I follow that mantra either, but recoignise the good elements) using a variation camel case and explicit naming, no shortened words, that are meaningful to the application. These standards were enforced throughout the company right down to the number of spaces between line items... And did it look good  , was easy to read and usually made sense.
Basically I do what I am told...
|
|
|
|
|
FirstName is obvious but how about blnResult, lngResult or (preferably NOT) strResult?
|
|
|
|
|
Well, it isn't an unsigned type either, so maybe you REALLY REALLY meant a logic statement like this:
if( nCycles > 0 )
instead of
if (nCycles != 0 )
since
if( nCycles )
and
if( nCycles != 0 )
get you the same result for a signed variable, don't they?
All along it maybe should have been:
unsigned int nCycles = 0;
...
if( nCycles > 0 )
...
Now THAT is a correction to a potentially serious problem!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
