Name of refactoring, regarding simplyifing conditional expression

[manuel aldana]

hi, because i don't want to name refactorings differently as they are accepted i am searching a name of following refactoring:

from:

    
public boolean method(){
  if(!something){
     //very very long code block somewhere return false
  }
  return true;
}

to:

    
public boolean method(){
  if(something)
     return true;
  //very very long code block somewhere return false
  return true;
}

partly it is Reverse Conditional. but my main point is that putting return true directly after if(something) makes it clearer that the method is "finished" immediately after a certain clause.

i am sure having read this example somewhere but i cannot remember the name.

thanks.
[ December 28, 2006: Message edited by: manuel aldana ]

[Stan James]

Hmmm, not sure about naming that technique, but I'd rather avoid it. How about

public boolean method()
{
  return something ? true : codeExtractedToNewMethod();
}

[fred Joly]

public boolean method()
{
  return something ? true : codeExtractedToNewMethod();
}   

I do not agree with this, with your method it is difficult to know what
the return type would be, wich was the main point.
Now what i'm asking myself is what is the point of having a return type at all
if it is always "true" ?

[Garrett Rowe]

I do not agree with this, with your method it is difficult to know what
the return type would be, wich was the main point.
Now what i'm asking myself is what is the point of having a return type at all
if it is always "true" ?

I not sure what you mean by this, the return type will always be a boolean, what makes you think that the method will always return true? The statement to me makes it clear that is *something* is true, the method will return true, if not it will return whatever codeExtractedToNewMethod() returns. Is your argument is that codeExtractedToNewMethod() means extra compexity in that you have to look at that method to infer the return value? Either way you'll be diving into a "very very long code block somewhere return false", the pain of which could possibly alleviated by even more refatoring into smaller methods (with descriptive method names of course).

[Ilja Preuss]

Seems to be a simple case of http://www.refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html

I like guard clauses, although I don't like very very long blocks of code.

[manuel aldana]

you're all right that 'extract method' must be the next refactoring step. i just left it away to know the refactoring name.

but after using extract method of course it is one copy of Replace Nested Conditional with Guard (Santa) Clauses . and it does not make really sense to find a name for an unfinished refactoring... so i am stopping searching for it now.

thanks.

[Stan James]

"guard clause" is just that early return on a condition, right? I liked the refactored version in the linked example. Even though some folks might cry "multiple returns!" it's very clear in intent.

Re that "very very long code block" we could easily to get into old fashioned functional decomposition. Which doesn't bother me a bit after we've made sure that all this code really belongs in this object. Then I like to look for a consistent level of abstraction, ie avoid mixing business terms with bit twiddling. So I suggested "something" and "codeExtractedToNewMethod" were at the same level of business or logical understanding. If that's not true, a different decomposition is called for.