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 assume 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." $$
