3 ms·

I don't quite follow -- in Joel's case, it's assumed that you're tracking the position of all sorts of things -- there isn't one variable that's the relative of

by starwed 15y ago

I don't quite follow -- in Joel's case, it's assumed that you're tracking the position of all sorts of things -- there isn't one variable that's the relative offset, but a whole host of them that you'd want to give particular semantic names. Prefixing them all with "relative_offset" would be unwieldy, so a concise, consistent prefix makes a lot of sense.

jasonwatkinspdx 15y ago
Short version: 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 starwed 15y ago

jasonwatkinspdx 15y ago

Short version: 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.