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... :D 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 class 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 class 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." $$
