I didn't even know there were multiple flavors of Hungarian notation



  • Where I work we don't appear to have any coding style guidelines. I'm working on it but am running into nitpicky resistance with just about everything. One of the horrors we have is that multiple developers use different flavors of Hungarian notation. Some examples from memory:

    The first style:

    for(int i_i32 = 0; i_i32 < height; i_i32++)
    {
        for(int j_i32 = 0; j_i32 < width; j_i32++)
        {
            float intensity_f32 = (float) image_aui8[stride_i32 * j_i32 + i_i32];
            // etc.
        }
    }
    

    The second style:

    mpoAnotherClassName = new CAnotherClassName(/*Snip 7 parameters in the same style*/);
    mpaucBuffer = new unsigned char[BUFFER_SIZE];
    

    poFoo = new CFoo();
    CBar oBar;

    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.

    It feels a bit like everything here is still stuck in the early 90s or so.



  • It sounds like subtle differences in the flavor of sys hungarian, not actually showing the difference between sys and apps.



  • @locallunatic said:

    It sounds like subtle differences in the flavor of sys hungarian, not actually showing the difference between sys and apps.

    Something like that, yes. I haven't seen anyone where I work use apps hungarian. Just subtly different versions of sys.



  • @witchdoctor said:

    @locallunatic said:

    It sounds like subtle differences in the flavor of sys hungarian, not actually showing the difference between sys and apps.

    Something like that, yes. I haven't seen anyone where I work use apps hungarian. Just subtly different versions of sys.

    My appologies, the title made it sound like you may not be aware of the diff between sys and apps (and most that don't know that assume there is only sys).



  • @locallunatic said:

    My appologies, the title made it sound like you may not be aware of the diff between sys and apps (and most that don't know that assume there is only sys).

    I admit that I wasn't thinking about apps hungarian while writing my post. I have a much smaller problem with apps hungarian that pretty much reduces to "why use a single letter when there's a perfectly useful word for what you want to express?". But sys is just evil and what most people think of when they read Hungarian notation.



  • @witchdoctor said:

    "why use a single letter when there's a perfectly useful word for what you want to express?"

    Because identifiers are limited to 6 or 8 characters, of course!



  • @morbiuswilters said:

    @witchdoctor said:
    "why use a single letter when there's a perfectly useful word for what you want to express?"
    Because identifiers are limited to 6 or 8 characters, of course!

    Actually there can be a reason to use apps instead of the word; not because you have limited length identifiers, but because your screen is only so wide.  Things are more readable if they fit on the screen in one line instead of needing to break the line up (or the "I'll murder you" choice of half the lines requiring me to scroll horizontally).



  • @locallunatic said:

    Actually there can be a reason to use apps instead of the word; not because you have limited length identifiers, but because your screen is only so wide.  Things are more readable if they fit on the screen in one line instead of needing to break the line up (or the "I'll murder you" choice of half the lines requiring me to scroll horizontally).

    In most cases if you need a statement that is that long something went wrong somewhere at the design stage. Using Apps Hungarian is mostly a band-aid because fixing the design would be too expensive.



  • @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!



  • @witchdoctor said:

    The first style:

    for(int i_i32 = 0; i_i32 < height; i_i32++)
    {
        for(int j_i32 = 0; j_i32 < width; j_i32++)
        {
            float intensity_f32 = (float) image_aui8[stride_i32 * j_i32 + i_i32];
            // etc.
        }
    }
    

    The second style:

    mpoAnotherClassName = new CAnotherClassName(/*Snip 7 parameters in the same style*/);
    mpaucBuffer = new unsigned char[BUFFER_SIZE];
    

    poFoo = new CFoo();
    CBar oBar;

    I'm guessing you either don't work with databases, or you haven't examined the table and column names closely yet....


  • @Tacroy said:

     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!

    Looks like it's time for drastic measures. Slaying the God-object. Pick the largest method in the God object, move to its own (possible horribly named) class, spend a few days getting it to compile in a test harness (some additional ugliness is allowed for this step, but for fucks sake don't stop before the next step). Then refactor that into something semi-sane. Repeat with the next-largest method.

    That requires some minimal political will to do this though. But the optimization looks like a good place to start this ball rolling.



  • @PJH said:

    I'm guessing you either don't work with databases, or you haven't examined the table and column names closely yet....

    I'm in a part of the code that doesn't do any database access. But I'm kind of scared to look at the database code anyway, afaik that uses the Sqlite C API directly and the spatialite extension.



  • I recommend trying one made with hot smokey paprika, and big chunky cubes of feather steak. Slow cook it at 140C (around 280F) for 2 and half hours.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.