> 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

Great point! If you put an arbitrary value in (and yeah, people will put
return true if they don't know any better), will this make the code even
more confusing? "return;" of course, is different (and only meaningful if
used to break a function).

Does the parser insert a "return;" for you, like the parser puts a ?> on the
end of a PHP script that doesn't have it (I heard it does, anyways; I, of
course, ALWAYS...).

Additionally, does anyone know if "return;" to close a code block out that
is exhausted (at the final "}") was ever meaningful, such as in other
languages?

I think in a lot of cases using surrogates is a better, scalable solution,
but that only matters if you need a "better, scalable solution." Depends on
coding style, preference, and the situational 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." $$