What's the benefit of not using Hungarian notation?
programmers.stackexchange.com
programmers.stackexchange.com
pos_x = curr_pos_x + diff_pos_x
pos_x_mm = curr_pos_x_mm + diff_pos_x_pix
edit: I just saw that this is basically what [1] is about.
I know there are myriad arguments about the editors being smart enough now to keep you from making the foo = foo instead of this.foo = foo mistake, but I just grew up on it and I like the clear obvious separation of 'that variable is a member variable' that m_ provides.
The rest of Hungarian notation though, never used it.
Oh and save the flames on m_, I've debated it to death, you aren't going to change my mind now. :)
I have to say that I have enjoyed ruby's variable conventions which are enforced by the language and seem to be much less abused.
As for mixed in a file, there's just no excuse for that. If you are the kind of religious zealot that thinks her rightness in bracketing style or naming convention is so superior that it should override the convention used in a file then you have no business coding on a team.
Although I don't agree with them :)
(EDIT: Oops, I answered you before seeing it's on the accepted answer on the article)
For semantic differences (eg Joel's absolute vs relative coordinates example) I think it's more reasonable, but I still dislike it as an idiosyncratic abbreviation. For example, why not just RelativeOffset vs relOffset. Or for locals, I prefer ruby style: relative_offset, though that's more of a nitpick.
I think well chosen names really limit the usefulness of abbreviated prefixes.
Google "lParam vs wParam". And yes, you're feeling lucky.
Long Version:
Sometimes what I'm suggesting is equal to unabbreviated Hungarian. But sometimes there's a nice semantic bonus, where from context it's clear what we're talking about.
For example, in a game you might have objects at some position that can move around in space, be organized in hierarchies, etc. So you're dealing with a lot of vectors. Sometimes these are vectors from the origin, sometimes vectors from one object to another, sometimes unit vectors.
Assume we're working in a language or library situation where we'd really prefer to just keep all these vectors the same type, say a vec3f type with 3 float members, xyz.
We could decide that hungarian notation would be a good way to avoid making mistakes due to interpreting a vector wrong. So we use the prefixes ov, rv, uv to indicate vectors from the world origin, vectors from one object to another, and unit vectors.
Imagine some actual typical variables we might have, say Position, Parent and SurfaceNormal.
Is ovPosition, rvParent, uvSurfaceNormal really superior?
In each of these cases, the semantic content of the hungarian prefix is redundant. Position vectors are always from origin. Parent vectors obviously relate one object to another. Surface normals are always going to be over the unit sphere. So it's not really adding any comprehension.
But it gets worse. Let's say that we implement some more complicated scene tree to our game, like to do articulated animation of a robot. Now our position vectors are actually relative vectors. If we were being hungarian, ovPosition would be a lie, so we have to change all instances. Which is great if we can just let Eclipse do it. But what if we've published a library or otherwise are committed to a name?
Oops.
This is one of the reasons why pseudo hungarian for parameter names in web services is a HORRIBLE idea.
By working on these kind of project you will understand that there is a clear need to have good nomenclature and naming standard for a project and modules which, in many cases, reassemble Hungarian notation (describing method's or variable's purpose, portability, performance implication, etc.).
2) less wrongness (when type has changed but the hungarian was not updated)
3) more readability and all that falls from that (although, this is an opinion and I'm sure others believe that hungarian is more readable)
4) better(faster to unique) tab completion
5) discovering the disease that hungarian was just a symptom of. That is a bad type system. There's only two good ones Strong and Duck.
Proly more but that's enough for me.
lParam, wParam
2) It's ugly.
If you ever need a semantic naming convention for closely related variables that are crucial to use correctly (encryptedCustomerInformation vs decryptedCustomerInformation), make up your own ad hoc.
Why is that? The only time I've ever seen 'Hungarian' notation cause maintenance problems is when a dev changed the type of a variable without adjusting the name accordingly. That's a problem with the developer, not the convention.
It's ugly.
That's purely subjective.
It may be trouble to determine what the prefixes mean. To have no pattern at all, IMO is not at all an improvement.
So, snake_case in Python and camelCase in JavaScript (with classes being initial Capital in both).
For identifier 'camelCase' use '驼写'
Non camelCase variables and CamelCase classes in Java for instance would really feel out of place to me, whereas using the same case conventions for some ruby code would feel equally 'wrong'.
When it comes to conventions like this, I don't think there's a substitute for having a "when in Rome" attitude. If you're writing some greenfield code, Rome is all the other projects in your language of choice. If you're adding some functionality to an existing piece of code, that existing piece of code is Rome.
Yeah, this is a good point. I come across as gung-ho in the parent but I have to admit I do submit to the "when in Rome" effect.
That said, if Rome is an absolute shambles, I might feel empowered to start anew ..
I usually try to find some sort of dominant naming scheme to follow and clean up old code left and right, but yeah, sometimes starting anew can be the only sane thing to do.
But then again, I have no problem going into a badly formatted hunk of code and fixing it. I have, on occasion, reformatted entire source directories because the original sources were so terrible.