Quick question about returning from a nested statement
If I have something like a loop or a bunch of if / else statements and I want to return a value from within a socket (see below), the best way to do it is to assign a value to a field or property and return that?
See below:
bool b;
public bool ifelse(int i)
{
if(i == 5)
{
b = true;
}
else
{
b = false;
}
return b;
}
source to share
Yes, that's good style.
An alternative (which would be bad ) would be to do this:
public bool ifelse(int i)
{
if(i == 5)
{
return true;
}
else
{
return false;
}
}
The reason multiple return points are considered bad is that, especially for larger methods, it is difficult to keep track of the flow of the program inside the method, as it can exit from any one . This can be a debugging nightmare. If you have a return variable that you assigned, you can view that variable and know exactly when it will be returned (from one place).
This is not always the case, as there are good sides and bad sides at every stylistic point in programming.
source to share
There are several views. I think most people (myself included) tend to come back as soon as you have an answer and no more work is needed. Some people will argue that you only need to go back to the last presentation of the method. However, in some situations it can make things more difficult.
As per what I suggested, your example will be shorter and simpler:
public bool ifelse(int i)
{
if(i == 5)
{
return true
}
return false
}
source to share
If b is only used to compute the return value for your method, you must make it a local variable (defined in the method).
public bool ifelse(int i)
{
bool b;
/*
Some code to calculate b
*/
return b;
}
As others have suggested, if your method is simple, I would avoid using a temporary variable altogether and return the result as soon as it was known. The general rule of thumb is to use the method that makes the code easier to read.
source to share
I would say that if at all you only have to return from the method in two places - at the beginning (as in defensive conditions) and towards the end; If the method is of any length, you must use a temp variable as you mentioned, otherwise people reading the code may have a more difficult time after it.
source to share
As noted, having more than one refund claim has the disadvantage of finding them. OTOH in some cases the added logic needed to escape into this return statement is even worse that the problem the style solves.
The main problem I am aware of is that you can quickly forget to do cleanup handling or the like at a new return point. IMHO this is also a single return form issue because the escape route has to remember to include this code and no other code. One solution to this, available in some languages such as C #, is a finally or neater block from a scope statement , as shown here . (OK, I'll get my soap box)
source to share