The gauntlet software pattern

I find code like this really confusing:

if a and b and c:

if d or e:
return True

elif f and g:
return True

else:
return False

Furthermore, updating those rules is nasty. I’m very likely to get something wrong, especially when “if a” is really some elaborate method call with several parameters.

It get a little more obvious when I flatten it out like this:

if a and b and c and (d or e or (f and g)):
return True

else:
return False

That looks OK for this contrived example, but imagine I need to stick in another clause that says also return True when a and g are True. It ain’t so easy to arrange the code any more.

Over the years, I’ve run into this situation a lot. Usually, I’m doing something like registering a new user, and I want to rule out that this new user is already in the database. So I have to look up the user on a variety of fields, like maybe email address, their user name, their mobile number, etc.

When I can boil the action down into something like “do this, unless any of these scenarios apply” I write the code in this format:


# Beginning of the gauntlet
if not a:
return False

if not b:
return False

if not c:
return False

if not d or e:
return False
# End of the gauntlet

return True

I put the fastest reasons to disqualify the action at the beginning. The really elaborate stuff belongs at the bottom.

Now,

10 thoughts on “The gauntlet software pattern

  1. For some reason SE-SE (Single Entry – Single Exit) code still has a strong cargo cult appeal. I've seen people write that way even though they weren't old enough to type when the last compiler that benefited from SESE went away.

    I much prefer multiple return statements. It says to the reader “you can stop reading this function now.”

  2. These articles are fantastic; the information you show us is interesting for everybody and is really good written. It’s just great!!

  3. The way your article is written illustrates your knowledge of great vocabulary and grammar. I am daunted by your thoughts and spectacular use of words and sentences.

  4. Error in code above — what if (a && b && c && !(d || e) && !(f && g))
    in the original code, nothing is returned, in both subsequent examples, different values are returned.

  5. I think an if else statement is just as efficient / readable and you can still end up with a single return statement.

    bool rValue = true;

    if( not a ){
      rValue = false;
    }else if (not b){
      rValue = false;
    }

    return rValue;

    multiple return statements turn into a nightmare when using loops.  My preference is to use a single return statement.  I have seen too many times where multiple statements turn ugly, and haven't yet see a use case where sticking to a single return is mutually exclusive from good code.  these are just my thoughts however.  they may be wrong.

  6. Hey, thanks for the comment!

    Stuff like this is largely a matter of taste rather than hard science. Your way is more readable to you, but for me, the multiple returns are a signal to me that I can immediately stop reading.

  7. The stop snore products you can end taking cigarette smoking and alcoholic beverages based drinks is probably among the best nasal loud snoring solutions that work well.

Comments are closed.