Naming Conventions

Admittedly, I’m not very good at coming up with names for things. If it were left up to me, the street in front of my house would simply be called, “The Street” and the street over by my friend Jeff’s would (at best) be called, “Jeff’s Street.” (It’s also quite possible that this other street would be called “The Other Street.”) But in some odd way, it’s still good to know that I’m better at names than some people.
For the longest time, my standard for poor naming conventions was a set of classes for managing the transitions between modules in a web application. The classes were named, “TransitionType1”, “TransitionType2” and “TransitionType3” which didn’t really convey much information about how they differed from one another. (The same developer was responsible for a set of login functions named “LoginType1”, “LoginType2” and so on up to “LoginType6.” By a not-so-amazing coincidece, that was also the order of the different types in the requirements, so it was slightly better, but still not particularly descriptive.)
Today I encountered the Holy Grail of interesting names. The names were completely descriptive, but still caused me to do a doubletake.
A blogging package I’ve been evaluating exposes a set of events you can capture for specialized processing as a user edits a post. You can’t capture the update event itself, but before and after the update, you can capture the delightfully named PrePostUpdate and PostPostUpdate events.
I’d love to be that creative with my own confusing names.