CodeSOD: On Deep Background

Andrew worked with Stuart. Stuart was one of those developers who didn’t talk to anyone except to complain about how stupid management was, or how stupid the other developers were. Stuart was also the kind of person who would suddenly go on a tear, write three thousand lines of code in an evening, and then submit an pull request. He wouldn’t respond to PR comments, however, and just wait until management needed the feature merged badly enough that someone said, “just approve it so we can move on.”

int iDisplayFlags = objectProps.DisplayInfo.BackgroundPrintFlags;

bool bForceBackgroundOn = false;
bool bForceBackgroundOff = false;

// Can't use _displayTypeID because it will always be 21 since text displays as image
if (_fileTypeID == 11) // TEXT
{
    if ((iDisplayFlags & 0x1008) != 0) // Text Background is required
    {
        bForceBackgroundOn = true;
    }
    else if ((iDisplayFlags & 0x1001) != 0) // Text Background is not available
    {
        bForceBackgroundOff = true;
    }
}
else if (_displayTypeID == 21) // IMAGE
{
    if ((iDisplayFlags & 0x1200) != 0) // Image Background is required
    {
        bForceBackgroundOn = true;
    }
    else if ((iDisplayFlags & 0x1040) != 0) // Image Background is not available
    {
        bForceBackgroundOff = true;
    }
}

bool useBackground = bForceBackgroundOn;

// If an object does not have an Background and we try to use it, bad things happen.
// So we check to see if we really have an Background, if not we don't want to try and use it
if (!useBackground && objectProps.DisplayInfo.Background)
{
    useBackground = Convert.ToBoolean(BackgroundShown);
}

if (bForceBackgroundOff)
{
    useBackground = false;
}

This code is inside of a document viewer application. As you might gather from skimming it, the viewer will display text (as an image) or images (as an image) and may or may not display a background as part of it.

This code, of course, uses a bunch of magic numbers and bitwise operators, which is always fun. We don’t need any constants. It’s important to note that all the other developers on the project did use enumerations and constants. The values were defined and well organized in the code- Stuart simply chose not to use them.

You’ll note that there’s some comments and confusion about how we can’t use _displayTypeID because text always displays as an image. I’m going to let Andrew explain this:

The client this code exists in renders text documents to images (for reasons that aren’t relevant) when presenting them to the user. We have a multitude of filetypes that we do similar actions with, and fileTypes are user configurable. Because of this, we also keep track of the display type. This allows the user to configure a multitude of filetypes, and depending on the display type configured for the file type, we know if we can show it in our viewer. In the case of display type ‘text’ our viewer ultimately renders the text as an image. At some point in time Stuart decided that since the final product of a text document is an image, we should convert display type text over to image when referencing it in code (hence the comment ‘Can’t use display type ID’). If none of this paragraph makes any sense to you, then you’re not alone, because the second someone competent got wind of this, they thankfully nixed the idea and display type text, went back to meaning display type text (aka this goes through OUR TEXT RENDERER).

What I get from that paragraph is that none of this makes sense, but it’s all Stuart’s fault.

What makes this special is that the developer is writing code to control a binary status: “do we show a background or not?”, but needs two booleans to handle this case. We have a bForceBackgroundOn and a bForceBackgroundOff.

So, tracing through, if we’re text and any of the bits 0x1008 are set in iDisplayFlags, we want the background on. Otherwise, if any of the bits 0x1001 are set, we want to force the background off. If it’s an image, we do the same thing, though for 0x1200 and 0x1040 respectively.

Then, we stuff bForceBackgroundOn into a different variable, useBackground. If that is false and a different property flag is set, we’ll check the value of BackgroundShown– which we choose to convert to boolean which implies that it isn’t a boolean, which raises its own questions, except it actually is a boolean value, and Stuart just didn’t understand how to deal with a nullable boolean. Finally, after all this work, we check the bForceBackgroundOff value, and if that’s true, we set useBackground to false.

I’ll be frank, none of this quite makes sense to me, and I can certainly imagine a world where the convoluted process of having a “on” and “forceOff” variable actually makes sense, so I’d almost think this code isn’t that bad- except for this little detail, from Andrew:

The final coup de grace is that all of the twisted logic for determining if the background is needed is completely unnecessary. When the call to retrieve the file to display is made, another method checks to see if the background was requested (useBackground), and performs the same logic check (albeit in a sane manner) as above.

The code is confusing and unnecessary.

Source: Read More