>
> Even the most simple function can have more than one failure point
> within it. If you aren't handling the errors yourself within the
> function, you're returning false all over the place and then having to
> do the same checking from whatever called it - duplicated however many
> times you call that function from your code.
>

I don't know if arbitrarily inserting a return true|false onto the end of a
function is going to make it future-proof; what if that changes from a
true|false to a 0|1, or you want/need to return null? Will you break all the
distributed procedural checks peppered all over the script? I posit, if
you're not experienced/bright enough to consider these factors when coding,
you will probably make a mistake anyways.

Code to what you need (be it functional, OO, whatever), but have high
standards...

I think putting "return;" at the end of every function is probably a healthy
practice, but is it best practice? If it's poorly written and/or poorly
factored code, it doesn't make any difference if they have returns on
everything, it's still junky code.

But I don't believe "return true/false" is a good practice, especially for
those who WOULD NOT normally use it due to inexperience. Putting an
artificial return value that is arbitrary isn't really all that useful, and
might in the future cause headaches (see above).

Do you put returns on __construct() and __destruct()? They are functions,
too.

And there are times when a true/false response is meaningless. For instance,
if you have a public value settor but you don't want the value to be seen
publicly, do you want to return it? Well, no. Would a boolean be useful?
Maybe, if you can regex against a pattern or something, or check for a null
or empty value.

Should those checks be contained in the codeblock or cl*** BEFORE returning?
I think so. In OOP (less in functional/procedural), I would make a
checkState() or isValueSet() or isUsable() method that returns boolean if
necessary (for example, a dependant object check), or push the logic into a
cl*** creation and check type on function call. I think this also makes the
code easier to understand and puts logic in it's place by type (functions,
methods, members, checks). You can also pool checks together to validate an
object member, meaning code reuse is in effect. Exceptions come in handy.

YMMV

But, y'know, I'm sure there are cases where this could be proven wrong, but
personally, I see them as edge-cases mostly, that must be known when the
code is written. Again, by paying close attention and refactoring (and
hopefully unit testing), this is a moot question anyways. PHP's soft-typing
complicates this further (0 == false == null == '' == ??????). This makes a
whole lot more sense in C++ or something other strong-typed language.

Thus, code to what you need, but have high standards (by knowing what you
need)!

--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$

Hi Jared,

Wednesday, May 30, 2007, 4:10:45 PM, you wrote:

[snip]
> I think putting "return;" at the end of every function is probably a healthy
> practice, but is it best practice? If it's poorly written and/or poorly
> factored code, it doesn't make any difference if they have returns on
> everything, it's still junky code.

If you do put a return; at the end of all of your functions, I'm
curious as to why? If a function doesn't actually return a value
(which is highly possible) then it isn't /required/, but that doesn't
stop me from doing it. I *do* put 'return;' at the end of all
functions (my question to the list was - does anyone else?)

That is all my original thread was ever really asking - I was just
curious what other people thought about returning from functions that
don't actually require a return value. So far the responses have been
pretty varied, from the (somewhat blinkered) 'how can a function never
return something?', to 'yes I always return' to 'no I just let it run
out'.

Based on the variety of replies it appears there is no 'standard' for
this. Just as with code structure and studly-caps it's obviously a bit
of a religious debate.

I think perhaps it is a psychological thing actually, as if I don't
consider the function 'finished' until it hits a return;. Almost like
you're issuing an instruction to tell PHP "yes, as the programmer I am
now happy for you to return to where-ever you were called from" -
perhaps just a way of exerting our control

> Should those checks be contained in the codeblock or cl*** BEFORE returning?
> I think so.

I would agree (because it's how I do it , but this isn't an approach
everyone takes.

Cheers,

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

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

----- Original Message -----
From: "Richard Davey" <EMAIL REMOVED>
> That is all my original thread was ever really asking - I was just
> curious what other people thought about returning from functions that
> don't actually require a return value. So far the responses have been
> pretty varied, from the (somewhat blinkered) 'how can a function never
> return something?', to 'yes I always return' to 'no I just let it run
> out'.
>

My rule is to write what you mean, and if you don't mean to return anything
valid or worth anything, just don't. If you explicitly put a return it
should be for a reason, whatever you return should be meaningful. If I find
a 'return true' at the end of a piece of code, I will check if there is any
condition where it returns false, because I will ***ume that the return true
is significant and so should be its obvious alternative. I would also
wonder why the caller doesn't use that return value or if it does, why is
there no 'else' part.

In a similar line, I use 'null' in databases when I mean 'I have no valid
information for this field'. Basically, the idea is to be clear in what you
mean. If you put a return it should be because you mean to return
something. If you mean you don't know, use 'null', don't default to zero or
any other implausible value for that field. This kind of arbitrary
conventions dilute the self-documenting value of well-written code, quite
the opposite, they would need to be documented themselves to avoid
missinterpretations.

Satyam

On Wed, 2007-05-30 at 17:24 +0100, Richard Davey wrote:
> Hi Jared,
>
> Wednesday, May 30, 2007, 4:10:45 PM, you wrote:
>
> [snip]
> > I think putting "return;" at the end of every function is probably a healthy
> > practice, but is it best practice? If it's poorly written and/or poorly
> > factored code, it doesn't make any difference if they have returns on
> > everything, it's still junky code.
>
> If you do put a return; at the end of all of your functions, I'm
> curious as to why? If a function doesn't actually return a value
> (which is highly possible) then it isn't /required/, but that doesn't
> stop me from doing it. I *do* put 'return;' at the end of all
> functions (my question to the list was - does anyone else?)

If there's no reason for it to return something, why bother? It's like
telling the reader of your code that they're a complete and utter moron
because obviously you need to point out explicitly that the code returns
at that point because they obviously couldn't infer it from having
reached the end of the function

Cheers,
Rob.
--
..------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'