[General Coding] Early Returning, better practice?

[+Majesticmerc MVC]

Take the following code for example...

Bool myFunction{
If (IamCool == True)
{
 Return true;
}
/*Do some other stuff here*/
return false;
}

Bool myFunction{
If (IamCool == True)
{
 Return true;
}
else
{
 /*Do some other stuff here*/
 return false;
}
}

Should one of these be used in preference to the other? I mean they do the same thing, so I can't see why not, but I've just done the former example in one of my projects, and it's made me curious.

Any comments appreciated,

-- El Sid

[GaZ]

i tend to structure my code all on new lines purly because it read easier to me, its preference. it all compiles to the same machine code. to use your example.

Bool myFunction

{

If (IamCool == True)

{

Return true;

}else{

/*Do some other stuff here*/

return false;

}

}

probably looks odd to some people but its how i can read it easily.

[d3nuo]

nm

[_kane81]

its a hard one..... if the logic is simple return (like switches), if not then only return at the end.

[primexx]

For clarity's sake i'd say stick to having if-else since it'll be easier to manually debug. Otherwise, the first is probably more efficient.

[C++]

Cleanest way to do this, IMO.

Bool myFunction {
	 If (IamCool == True) {
		  Return true;
	 } else {
		  /*Do some other stuff here*/
		  return false;
	 }
 }

[Daem0hn]

the 'correct' way as defined by some programming design schema somewhere (or maybe thats just something my uni lecturer made up to impress us into following his convention) says that functions should only have one point of return. I love multiple returns, especially inside short and simple functions, however if you pursue a programming course at university, you will loose marks if you use multiple return statements.

the way that universities like you to use is:

Bool myFunction {
   Bool result=false;
   If (IamCool) //note you dont need the ==True assuming IamCool is a boolean
   {
	  result=true;
   }
   else
   {
	  //do stuff
   }
return result;
}

its a little longer, but the idea is you have one variable that tracks the return status of the function (in the case of a boolean return). supposedly this makes it alot easier to debug and to follow the code through if it isnt performing as it should.

[+Majesticmerc MVC]

I see where you are coming from Daem0hn, I have been taught along the same lines at my university, however take, for example, that you have a function that returns an integer to inform the function that called it how successful it was at executing.

The to-be-returned integer holds a number representing how successful the function was, and certain sections of the function have particular failure numbers. Now if each section of the function relies on the previous section to go run without a problem, the to-be-returned integer would have to be checked each time to make sure the subsequent functions could run. This would in turn result in if statements coming out of the wazoo, and you'd end up with (admittedly minute) overhead creeping into a function that could have aborted as soon as the initial problem occurred... If that makes sense.

[Winston]

Wait, isn't he asking if he should have else or shouldn't have the else?

I'm not sure what the difference would be, but i'm assuming, if there's an extra path (the else clause), wouldn't that make any extra path for testing?

[_kane81]

^

opps yeah he is.... well a bit of both.

leave out the else unless it has more if elses.

I'm not sure what the difference would be, but i'm assuming, if there's an extra path (the else clause), wouldn't that make any extra path for testing?

I wouldnt say so. it is still a path. in factI would say the compiler would optimise the code so that it run exactly the same with or without an else statement in it.

[azcodemonkey]

IMO, it doesn't matter. Some would argue that you should have only one exit point for a method. As far as I'm concerned, as long as the code makes sense, you can return early or have multiple points of exit.

[see-seA]

Do the way that makes the most sense to you. If you don't think others will follows, or if in a few months time you'll struggle to understand what you did, then comment. Unless, of course, you're doing a programming course and they expect you to follow a certain method.