Hi all,

Just a quick straw-poll really:

What is your take on using 'return' when you end a function, if you
don't actually need to return a value?

If you have to return say a true/false as the result of an operation,
then it's an obvious choice. But what if all the function does is
perform an action and then quit? Do you like to use 'return' at the
end of it anyway, or do you just let it run into the closing } ?

Or do you perhaps do a 'return true' at the end, regardless, even if
the rest of your code never checks that value (on the basis that it
may do in the future)

Cheers,

Rich
--
Zend Certified Engineer
http://www.corephp.co.uk

"Never trust a computer you can't throw out of a window"

Richard Davey wrote:
> Hi all,
>
> Just a quick straw-poll really:
>
> What is your take on using 'return' when you end a function, if you
> don't actually need to return a value?
>
> If you have to return say a true/false as the result of an operation,
> then it's an obvious choice. But what if all the function does is
> perform an action and then quit? Do you like to use 'return' at the
> end of it anyway, or do you just let it run into the closing } ?
>
> Or do you perhaps do a 'return true' at the end, regardless, even if
> the rest of your code never checks that value (on the basis that it
> may do in the future)
>
> Cheers,
>
> Rich

In such cases it depends on the project I'm working on. If it's a
slightly bigger project which will see future development, I usually
stick to a return true|false policy even though such functions don't
have a meaningful return (YET!), as this might change later.
If it's a project which will be used but probably won't see any
extensive future development, I generally tend to not return anything.

- Tul

> Just a quick straw-poll really:
>
> What is your take on using 'return' when you end a function, if you
> don't actually need to return a value?
>
> If you have to return say a true/false as the result of an operation,
> then it's an obvious choice. But what if all the function does is
> perform an action and then quit? Do you like to use 'return' at the
> end of it anyway, or do you just let it run into the closing } ?
>
> Or do you perhaps do a 'return true' at the end, regardless, even if
> the rest of your code never checks that value (on the basis that it
> may do in the future)
>

I like to have all my functions return something so use return true.

Edward

If there is no need to return a value then I don't do so. However, the
function is going to process something, and surely you should check that the
processing has succeeded or failed?

Hi Dave,

Wednesday, May 30, 2007, 12:20:48 PM, you wrote:

> If there is no need to return a value then I don't do so. However, the
> function is going to process something, and surely you should check that the
> processing has succeeded or failed?

I have exception and error handling dealt with fully in my functions,
by which stage the 'return' at the end becomes redundant because the
return value doesn't need checking as the error handler has already
taken over. However take the following:

$result = $this->calculateSomething($value);

If 'calculateSomething' has all the error handling it requires built
into it, then isn't checking the value of 'result' superfluous to
requirements? Yet even so, I still like to return something at the end
regardless

I guess another way to phrase the same question would be where do you
shift all of your error handling - inside the function itself, or in
the code that calls it (i.e. checking the $result in the example
above). Personally I handle it all in the function otherwise I'm
duplicating m***es of result checking.

It isn't a case of wrong/right, just trying to gauge preferences here.

Cheers,

Rich
--
Zend Certified Engineer
http://www.corephp.co.uk

"Never trust a computer you can't throw out of a window"

On Wed, 2007-05-30 at 12:20 +0100, Dave Goodchild wrote:
> If there is no need to return a value then I don't do so. However, the
> function is going to process something, and surely you should check that the
> processing has succeeded or failed?

If you unit test, then returns become quite important, so I almost
always return;

--Paul


All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/...imer/index.htm

2007. 05. 30, szerda keltezéssel 11.52-kor Richard Davey ezt ÃÂ*rta:
> Hi all,
>
> Just a quick straw-poll really:
>
> What is your take on using 'return' when you end a function, if you
> don't actually need to return a value?
>
> If you have to return say a true/false as the result of an operation,
> then it's an obvious choice. But what if all the function does is
> perform an action and then quit? Do you like to use 'return' at the
> end of it anyway, or do you just let it run into the closing } ?
>
> Or do you perhaps do a 'return true' at the end, regardless, even if
> the rest of your code never checks that value (on the basis that it
> may do in the future)

personally I prefer to use return only if I need the return value for
something. If it's not used then I think it's just a waste of code lines
and resources to return anything...

greets
Zoltán Németh

>
> Cheers,
>
> Rich
> --
> Zend Certified Engineer
> http://www.corephp.co.uk
>
> "Never trust a computer you can't throw out of a window"
>

On Wed, May 30, 2007 5:52 am, Richard Davey wrote:
> Just a quick straw-poll really:
>
> What is your take on using 'return' when you end a function, if you
> don't actually need to return a value?
>
> If you have to return say a true/false as the result of an operation,
> then it's an obvious choice. But what if all the function does is
> perform an action and then quit? Do you like to use 'return' at the
> end of it anyway, or do you just let it run into the closing } ?
>
> Or do you perhaps do a 'return true' at the end, regardless, even if
> the rest of your code never checks that value (on the basis that it
> may do in the future)

Planning for a return value that you might need but have no idea what
it will be is probably a Bad Idea -- You'll just need to document it,
maintain it, etc for no real reason.

If the function is only called for side-effects (I.e., it returns
nothing) then don't return anything -- You'll know by looking at the
end of the function that it's not supposed to return anything.

Adding the gratuitous 'return' seems of dubious benefit.

I rarely write a function that doesn't return anything, come to think
of it...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

On May 30, 2007, at 6:32 AM, Richard Davey wrote:

> Hi Dave,
>
> Wednesday, May 30, 2007, 12:20:48 PM, you wrote:
>
>> If there is no need to return a value then I don't do so. However,
>> the
>> function is going to process something, and surely you should
>> check that the
>> processing has succeeded or failed?
>
> I have exception and error handling dealt with fully in my functions,
> by which stage the 'return' at the end becomes redundant because the
> return value doesn't need checking as the error handler has already
> taken over. However take the following:
>
> $result = $this->calculateSomething($value);
>
> If 'calculateSomething' has all the error handling it requires built
> into it, then isn't checking the value of 'result' superfluous to
> requirements? Yet even so, I still like to return something at the end
> regardless

I normally (but not always) return (whether I will actually use that
value or not).


> I guess another way to phrase the same question would be where do you
> shift all of your error handling - inside the function itself, or in
> the code that calls it (i.e. checking the $result in the example
> above). Personally I handle it all in the function otherwise I'm
> duplicating m***es of result checking.

I spent some time thinking about this exact question and I came up
with several things:

1. How does PHP do it?

They have a function which performs whatever and returns an error
(code) upon failing. This allows every developer to deal with the
error in their own way.

2. Does this function need to be portable? (Short answer, yes, it
*should* be.)

Take these functions for example:

<?
function doSomethingToA ($a)
{
if (!$a) $_SESSION["not_portable"] = false;
else $_SESSION["not_portable"] = true;
return; // optional
}

function doSomethingToB ($b)
{
if (!$b) return false;
else return true;
}

// Non-portable function that probably won't work outside this
application
doSomethingToA ($_SESSION["whatever"]);

// Portable function that you can take anywhere! =D
$_SESSION["portable"] = doSomethingToB ($_SESSION["whatever"]);
?>

Yes, you may have to do some more error-checking on the outside of
the function. However, the question comes down to... what's your use
for it. It's almost a religious question - it's up to you on how you
code. Just be sure to weigh all the options.

~Philip


> It isn't a case of wrong/right, just trying to gauge preferences here.
>
> Cheers,
>
> Rich