Don’t Use Failure Names.. You’ll See What I Mean
Listen, this my first blog, and its not going to be that deep of a conversation, but its something that i see all the time, and in my personal and semi-professional opinion it’s incredibly annoying, and even more important, pretty stupid.
Do not, under any circumstances, give “Failure” names to boolean values. This is what i mean:
bool unsuccessful = true; //stupid bool successful = true; //smart
You might be thinking, “this isn’t a big deal Kercheval.. why are you writing about this.” But it is a big deal, and this is why. This is something I’ve seen in industry, and has caused me headaches. When communicating with hardware, you often send and receive information/data in raw bytes, and each bit is some sort of flag. So say we have a byte that we get back from the hardware, and one of the bits represent an error. Say a communication error. Do you see the problem? It might be obvious to me because the problem punched me right in the face… So lets say its the right most bit that is the “Communication Error” bit. The code to see if there was an error would be:
byte result = getInformationFromHardware(); //so we went out to the hardware and communicated and it returned a byte of information bool failure = result & 0x01; //we bitwise and the result with 1 to get the right bit and if the bit is set, this represents a communication error
Ok.. this isn’t too bad. Seems reasonable.. But wait.. what are the default values for bytes, and shorts, and ints. 0. So if getInformationFromHardware() is really a c++ function and it doesn’t throw exceptions on failures (because it has the failure bits to tell you if there is an exception), but if there is an error and the return value never gets set then you have a good chance that you get the default value, 0, back. But since you named your variable “communication error”, or “failure”, then the bit has to be set to indicate a failure, but it never got set because there was a failure. So i assume success. Do you see why this is stupid now? You’re setting a value to indicate failure, but if there is a failure where you are not expecting it, the failure might cause the failure bit to not get set. Wow. Now i know this isn’t going to happen often, because usually (i develop in c# by the way) your managed code will call other managed code that will throw exceptions on errors, but if you’re calling unmanaged code, as is the case when you work with hardware, (from what I’ve seen) the code tends not to throw exceptions, because it tends to rely on return codes. (Although you can catch native exceptions use the Win32Exception class, and probably should have unmanaged code always wrapped in some sort of try/catch block. )
So while this probably isn’t the case most of the time, it was a headache for me because someone decided to name their variable a “Failure” name.
Ok. This wasn’t the most exciting or mind blowing post. But i felt i needed to share why you should never do such a thing.