Should a method have only one return point/statement?

Question

Hi,
sometimes I have Code that looks like
  public boolean equals(final Object o) {
    if (o == null) {
      return false;
    if (o == this) {
      return true;
    if (!getClass().equals(o.getClass())) {
      return false;
    if (this.getId() == 0) {
      return false;
    final Link cObject = (Link) o;
    if (this.id != cObject.id) {
      return false;
    if (!this.linkParameter.equals(cObject.linkParameter)) {
      return false;
    if (!this.uriType.equals(cObject.uriType)) {
      return false;
    return true;
  }Is it best practice to use return in this manner? Some code metric tools report this use of return as bad coding practice.
What are the pros and cons of the short return?
Thanks for your answers

Answer 1

tmnelson wrote:
So we should pervert exception handling by putting all our code into try/finally blocks? I don't think that's gonna fly...That doesn't make much sense to me and I don't know what it has to do with what I said. One of the good reasons for forcing a single return is that you can put all the required cleanup code at the end of the method. Finally blocks accomplish this same end. This is not a perversion. In fact, finally blocks are superior in this regard because they are guaranteed to execute, even if the method doesn't complete normally. Single return cannot make this guarantee.
Um, I still only see one return. Only now it's in the wrong place. Why not just add the appropriate else clause to the original code? That's what you're going to wind up doing in your "improved" code, anyway.You seem to have completely missed the point. Both code snippets are wrong. My improved version doesn't compile. It's impossible to miss. The other version was deployed into production. In my experience a compilation error is a much better problem to have than a production system crash.
I don't see any value in forcing the single return. Actually I think it generally makes code much harder to read. It turns the execution path from a tree into an onion.I think it's a good rule of thumb, up there with placing braces after your if statement and documenting when a case statement falls through. It was more important when people wrote 100+line functions, as it was mighty confusing to place a breakpoint at some line and then never hit it because the code executed a return twenty or so lines before your breakpoint. This is still a potential problem today, but people tend to write shorter routines, so it's less common.It's a rule of thumb that makes sense in languages without the high-level control structures that Java has. COBOL is an example of such a language where forcing single returns is really important but it doesn't have a true method structure. It doesn't make sense in Java. And for long methods, the proper advice is to shorten them, not to force a single return.
ISTR that compilers could perform certain register optimizations if routines only had one entry and exit point, but I can't find a definite reference, and that may have only been valid for block-structured programs anyway. Or loops.This is complete nonsense. The compiler or JVM can optimize your code much better than anything like this will accomplish. There's no reason that the JVM can't treat a method with multiple return statements as having a single return statement given that all paths are guaranteed to return a value of a specific type or an exception will be thrown.
If you just declare the variable and don't assign it, the compiler will complain if there is a path that doesn't guarantee that it is assigned before it is used.This doesn't work in many IDEs, as the editor won't perform much static analysis, it'll just flag the declaration as an error and refuse to compile the code until you "fix" it.I didn't mention IDEs. This is part of the Java Language Specification. No compliant compiler will allow such code to be compiled.