hungarian notation

I realized I was almost on the verge of forgetting the term "Hungarian Notation" - a now mostly rejected idea of prefixing variable names with the type of the object. It was probably rejected because it was misunderstood and misapplied - like you shouldn't call your incrementer iCounter just because it's an integer, but if you have, say, a screen dimension that might be in pixels or might be in em, it might make sense to have "pxWidth" or "emWidth".

For instance, I'm fooling around with a gimmicky 3D for my timeline data, and some of my dates are objects containing a y and m key for month and year, sometimes I'm using a "count of months" (i.e. y * 12 + m) and sometimes I've normalized it to a value between 0 and 1. Hungarian Notation kind of makes sense here.

(To google up the forgotten term I had to search "notation petzold" - ah, the old Petzold book "Programming Windows", what an artifact of my first programming job...)

UPDATE: My online pal Jeremy Penner of Glorious Trainwrecks and the Fringe Games podcast worked with Charles Simonyi (inventor of "hungarian notation") and told me about his experience with it:

Anyway, the whole system was written from the ground up using Hungarian notation, and it turns out that it's actually a very interesting mental hack with very unintuitive properties

Kirk

So, for example, the thing everyone complains about, where coming to a new codebase is totally impenetrable? Like "what the fuck is an mpfuidsibst?" It turns out that's a huge tradeoff that absolutely makes sense when you're building something totally new, in that you don't assume anything about what an mpfuidsibst is. You KNOW you don't understand it instead of believing you have a fuzzy understanding that is actually incorrect.

(mpfuidsibst is a name I gave a thing and it is my go-to example of "this name makes complete sense in context but is utterly absurd to outsiders")

The other huge benefit is that it allows you to talk precisely about different things that are similar and would be given similar names

So instead of talking about an "event", and being unsure of whether you meant a win32 API event, or an internal UI event, or a "document modified" event, all of which are dispatched slightly differently and have different properties, you would have a unique short name for each, that you use consistently

The names are cryptic because they're short, and they're short so that you always say the full name out loud and don't abbreviate, so you are always precise in what you're talking about

It's as much a research collaboration tool as anything

And once you've bought in to the system, and you learn what things mean, it's incredibly effective at preventing misunderstandings

Kirk

Heh, interesting. In some React/Redux tutorials, I've noticed some times when the naming gets a little fuzzy, like "todos" might mean the JSON object map in memory as state, or as the reducers that tell you how to apply a change to the old state to get a new state