On Saturday, February 8, 2003, 4:01:09 AM, Austin wrote:

> In the thread on return values from assertions, I have seen a couple
> of people express that they prefer functions/methods without
> meaningful return values to return nil. Given that Ruby is a
> dynamically typed, expression-oriented language, this makes no sense
> to me.

> Even if the return value of a method is meaningless and not
> guaranteed to be something useful (a documentation matter, IMO),
> that doesn't mean that it doesn't provide value. In particular,
> since nil is a Boolean false value, returning nil from these methods
> means that the method cannot be used in a test, as it is always
> "false".

But if you're not going out of your way to actually return a value,
you could return nil even on success, so it can't (reliably) be used
as a test anyway.

You're right that it's a documentation issue.  However, code is
documentation sometimes.  Seeing "nil" at the bottom of a method gives
the hint that you aren't getting a useful return value, i.e. it is
sematically a procedure.

I don't usually do this with my own code, but I recommend it for a
published framework, since adopting defensive coding standards is one
way to keep misguided bug reports, etc., to a minimum.

Gavin