@witchdoctor said:
Additionally all classes have a C prefix, structs have a T prefix and enums have an E prefix and a small e prefix for enum values, so for example there could be an EElementType with elements eTypeOne, eTypeTwo, etc. This is apparently the ONLY thing that looks pretty much universal about the style practiced here.
I have a story like that! At my work, every single member variable of the all-encompassing godobject is prefixed with "j". Why? God only knows. But all new fields must follow that prefixing. So we've got jPrice, jVelocity, jWhatever.
Oh yeah and in our subsidiary godobject, which covers everything the overgod doesn't, almost every field is duplicated. Because (and this is using a car analogy) the object refers to both a Driver and a Passenger. So every field is prefixed with cD or cP. Why is the C there? I don't know and I don't think anyone else does either. But all new fields must maintain consistency with the old fields!
But I do know why there's a Driver and a Passenger prefix - because back when things were being developed, nobody thought "hey there's a glob of information that belongs together, we should group it into an object named, I don't know, Person or something". After all, the driver and passenger can (in most cases) swap positions with a short pit stop, so it would make sense to group the person data together and make it independent of which position they're in, right? No, instead they just started slapping field member on there. So now we're stuck refering to cDHeight and cPHeight, and creating both fields whenever we need to add something to the godobject.
The best part of this, though, is that at some point in the past some mad genius saw that it would be really really nice to have an Occupant object, so that when we wrote code that did essentially the same thing to both the Passenger and the Driver we wouldn't have to write two different versions (one with cD everywhere and the other with cP everywhere). His solution? It makes me burn with the rage of a thousand suns, but instead of doing some (oh idk) refactoring and maybe injecting sanity into the codebase, what he did was he created a bunch of fields without the D and P (so cHeight), and then making those fields check a state variable in the god object so they know who to refer to.
So now, when you see something like:
... code ...
occupants.cHeight = 100;
... code ...
You have no fucking clue whether it's refering to the Passenger's height or the Driver's height. You have to search through the code for the most proximate assignment to occupants.OccupantType to figure it out, but since it's a state variable in the godobject you never have any guarantees that something else didn't change it when you weren't looking. Oh and did I mention that there's some really performance critical code we'd very much like to optimize, but we can't because this sort of shit makes it impossible to reason about what's going on? And don't even mention testing.
(oh yeah and also we have some issues because your car can only ever have Passengers and Drivers in pairs, even though there can be more people in a car than the Passenger and Driver. So we carry a list of Passenger and Driver pairs. Because that makes more sense than just splitting the thing into separate objects.)
The only good part is that at least it's consistent, really. Of course, once you leave the jealously guarded realm of the God Objects, things like naming schemes start falling apart... but you can't have everything, I guess!