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,
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.”
Yup — that's exactly what I'm going for here; that flag that says
“you're all done!”.
What is up with those one-return-statement guys?
Folks, that pattern already has its name: it's “guard clause”. See http://c2.com/cgi/wiki?GuardCl… or http://www.refactoring.com/cat…
Przemyslaw — thanks for the links!
These articles are fantastic; the information you show us is interesting for everybody and is really good written. It’s just great!!
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.
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.
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.
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.
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.