Re: Multiple return statements in a function.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2009/4/23 Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx>:
>
> "tedd" <tedd.sperling@xxxxxxxxx> wrote in message
> news:p06240805c6161613a715@[192.168.1.101]...
>> At 8:12 AM -0400 4/23/09, Peter van der Does wrote:
>>>I tend to put my return value in a variable and at the end of the
>>>function I have 1 return statement.
>>>I have seen others doing returns in the middle of the function.
>>>
>>>-snip-
>>>
>>>What is your take? And is there any benefit to either method?
>>>
>>>Peter van der Does
>>
>> Peter:
>>
>> It's called "Structured programming" -- one way in and one way out of a
>> function.
>>
>> There are, of course, exceptions where it might help others reviewing your
>> code to see what's going on, such as returning a null value if the
>> argument(s) provided are not suitable. But normally the rule is, do not
>> provide an exit from a function in more than one place.
>
> There is no such "rule", it is a matter of personal preference. As a
> previous poster has already said, if you want to leave a function early and
> ignore all subsequent processing it is easier to understand if you return
> immediately rather than have a mechanism to jump over the remaining code to
> a single return point. In the good old days we used to use the GOTO in COBOL
> to jump to the exit point, but then people found a way to abuse GOTO in very
> imaginatve ways.
>
>> The "benefit" is easier to read code.
>
> I think that an immediate return is easier to read, but what do I know -
> I've only been programming for 30 years.
>
> --
> Tony Marston
> http://www.tonymarston.net
> http://www.radicore.org
>
>> Cheers,
>>
>> tedd
>>
>> --
>> -------
>> http://sperling.com  http://ancientstones.com  http://earthstones.com
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

As someone's who been playing this game for only 29 years, I like a
single exit point.

One of the issues I found with multiple exit points is that you have
to work a little harder to guarantee a return.

I always write my code so that if the function did nothing, then null
or false are the return values ...

function foo() {
 $result = False;
// ... code which may or may nor affect $result
 return $result;
}

If your code is heavily nested (maybe an indicator that some
refactoring is worth undertaking) and you introduce yet more code,
keeping track of multiple exit points can be a little problematic.

I suppose if you are the only developer then create a style and stick with it.

Don't be afraid of refactoring your code if you feel that a different
style is easier to work with.

If you work in a team, then once the team has determined its style,
stick with it. Even if it hurts. The hassle you'll get when your code
doesn't "fit" is far more than the learning curve you'll go through
getting the style.

Richard.


-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux