Apoch's Peeve Corner

Published July 23, 2007
Advertisement
Alright kiddies, it's time for another episode of... Apoch's Pet Peeve Corner! Yayy!

This is the segment of the show where Apoch picks some random thing and rants about it for a few minutes. Today, we're going to talk about: boolean valued functions.

(By the way, all of this discussion can be applied to any programming language; I'll be using C++ since it's a widely recognizable syntax. Feel free to adjust the lessons of this rant to the language of your choice.)


So let's say we have a complicated operation, called Frobnicate. This operation does something which may fail, and may succeed. We need to encapsulate the Frobnicate operation into a function call.

Let's write a prototype for our new function: bool Frobnicate();

That was easy, right? On to step two!


BZZZT - WRONG. Please turn in your programmer's license and shuffle away in shame. You have failed.

Frobnicate is not a boolean function. But Apoch, you protest, surely it can either succeed (true) or fail (false)! Yeah, but it can also succeed (false) or fail (true) depending on your style.

A boolean function should only be used for a predicate - a function which asks a yes/no question. So if we have a function IsBork, it can be boolean: either we're Bork, or we are not Bork. But Frobnicate does not ask a yes/no question. Therefore we should not use a boolean-valued function.



There are two ways to handle this situation and make Frobnicate correct:

Error Returns
If your code style uses error returns (that is, functions return whether or not they succeed, and possibly return special constants that indicate the result of the function call) then your solution is simple.

You should have, as part of your standard header package (and please tell me you have a standard set of precompiled headers/boilerplate code/etc. for your projects!) a simple enumeration which handles success/fail returns. Instead of returning true/false, return Success or Fail. This is extremely common in C and C++ land; Win32 and DirectX use this style, for instance.

The solution here looks like this: ResultCode Frobnicate();

Exceptions
If your coding style is to use exceptions, Frobnicate should probably not return a value. Either it throws an exception (something is wrong) or it does not (everything is fine).

The solution looks like this: void Frobnicate();



There you go. Now please, stop creating bool functions for success/fail results. Also, please don't bother assigning a return type to the function if all it ever does is return true;.

Thank you. This has been Apoch's Pet Peeve Corner.

Up next: dancing clowns juggling rabid hyenas! Don't go away!
0 likes 6 comments

Comments

Programmer16
Weird, that's one of the things I changed in my code library when I started rewriting it. Good timing I guess.
July 23, 2007 10:41 PM
DukeAtreides076
Let's not forget the dreaded FILE_NOT_FOUND functions.
July 23, 2007 11:23 PM
benryves
I occasionally find boolean-returning functions to be quite useful for things you want to attempt that fail in normal use.

For example, int int.Parse(string) will throw an exception if the string can't be parsed. If you have a text input box prompting for a number and are letting users loose on it, chances are it will throw an exception in normal use. I prefer to use bool int.TryParse(string, out int) and avoid the overhead of an exception.
July 24, 2007 05:23 AM
Ravuya
I stopped doing that upon the realization there are many reasons why a call to Frobnicate would fail, and you might want to know about them so you can pop up an error or deal with it in general.
July 24, 2007 12:45 PM
jollyjeffers
I recently saw some C# code using a Nullable return type to indicate success/failure. To this day I'm not entirely sure what the client code is supposed to do when there is no return code... [oh]
July 24, 2007 12:57 PM
ApochPiQ
Quote:Original post by benryves
I occasionally find boolean-returning functions to be quite useful for things you want to attempt that fail in normal use.

For example, int int.Parse(string) will throw an exception if the string can't be parsed. If you have a text input box prompting for a number and are letting users loose on it, chances are it will throw an exception in normal use. I prefer to use bool int.TryParse(string, out int) and avoid the overhead of an exception.


Incidentally, this is one of my bigger gripes with the design decisions in the .Net library. If they'd built in a native success/fail type (which could be extended selectively with additional return codes as needed), we wouldn't have this problem, at least not in .Net languages.

But nooooo.
July 24, 2007 10:51 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement