What's the difference between `return;` and no return?

Is there a difference between:

function someMethod( $someArg ) {
  // some code
  return;
}

and

function someMethod( $someArg ) {
  // some code
  // no return
}

Both have NULL as 'return value'. Is there a difference? Something PHP internally? Performance? Speed?

edit

I ask, because in Zend framework (in this video) they use return; which seemed (seems) silly to me. However, y开发者_JAVA技巧ou would think that the people behind Zend framework do know their PHP...

php code

<?php

function a() {
   echo 1;
   return;
}

function b() {
   echo 2;
}

generated bytecode

.FUNCTION a
        ECHO                     1
        RETURN                   NULL
        RETURN                   NULL
        HANDLE_EXCEPTION         
.END FUNCTION

.FUNCTION b
        ECHO                     2
        RETURN                   NULL
        HANDLE_EXCEPTION         
.END FUNCTION

so the explicit return statement generates one extra RETURN instruction. Otherwise there's no difference.

As far as I know there is no difference.

The empty return; is mainly there to break out from a if/else, while or for loop without returning anything.

Functionally there's no difference but it's always nice to have an obvious point of exit in a function (the return). Some schools of computer science hold tht all functions and methods should have precisely 1, and only 1, point of exit.

Should you need to add a return value in the future then there's an obvious point already picked out for you in the code if you include an empty return.

But like I said, from a functional point of view there's not much difference.

In your example, no difference.

However, return will terminate the function, so you have the option to skip code after the return statement (that's its purpose).

In your example, it is personal preference if you like to see the return or not.

Further, in some languages like Perl, the last expression is "implicitly" the return value, so you don't even need to use "return". (This won't work in other languages like C++, though.)

sub foo {
  return 12;
}

sub foo2 {
  12;  # same thing
}

There isn't a major difference, you can just use return; to break out of a function call early. They will both return NULL either way, it's strictly for workflow.

In language such as PHP and Python there's no real difference. return; can be used to break out of the function prematurely.

However, there is a difference when the programming language of choice is C/C++, Java, C#, where no return signifies a void

I'm no expert but I would say that if there is a difference in negligible; one could argue that your using up bites by putting return; or return false; at the end of a function.

typically I use return with something like

return true;

or

return $var;

and if i don't want to return anything or I want to return false I just don't use return

As soon as return is called, the function call is terminated. It acts like a break. So if your return is in the middle, it would gain some performance because the rest of the function isn't executed.

For the rest, it is often better (in a readability manner) to use an explicit return in stead of a implicit one. If you keep the return in the function, you will know that a call to that function might expect a return value.

return will break/exit the function (think break as in switch/case)

function someMethod( $someArg ) {
    if(condition) {
        return; // will exit function
    }

    // could be more code
}

I sometimes like to use an "empty" return as the last statement of a function as a friendly reminder that the function is not expected to return any value.

class foo {
  var $name;

  public function bar($x) {
    $this->name = $x;
    return;
  }
}

In ADA you have procedures and functions. The first do not return any data, they just execute some statements. The functions can return data.

So an empty return would be like 'this is a procedure'.

Very interestingly (I think), having a return type makes a lot of difference. Three kinds of returning null throw three different errors:

function foo() : string {
  // return nothing

  // TypeError exception: Return value of foo() must be of the type string, none returned
}

function foo() : string {
  return;

  // Fatal error: A function with return type must return a value
}

function foo() : string {
  return null;

  // TypeError exception: Return value of foo() must be of the type string, null returned
}

I would not have guessed that, since all errors are runtime and all return values are technically null.