[Please note that I am way behind on my ruby-talk reading. If you need a quick response, email me directly.]
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”.
-a
···
–
austin ziegler
Sent from my Treo
-----Original Message-----
From: Gavin Sinclair
Date: 03.2.5 22.53
To: ruby-talk@ruby-lang.org (ruby-talk ML)
Subj: Re: Return values from assertions
On Thursday, February 6, 2003, 2:42:16 PM, nathaniel wrote:
Is there a good rule of thumb for what methods should do
when they don’t have a useful value to return? I can’t remember seeing
any code that was careful to always return nil, but that could just be
my limited reading.
I don’t know about rule of thumb, but I would prefer to see nil
returned. We rely on documentation to specify APIs in Ruby, since no
type declarations do that for us, and keeping things uniform and
documented would serve Test::Unit well.
If the method fails, it should raise an exception. In which case the
return value is worthless- if it would be false, you’d never know because
the exception would already have been triggered.
Testing a meaningless output should be discouraged by always having the
method return nil. It’s painful for C developers to trust the exception
mechanism, but it makes for much cleaner code.
begin
do_thing
do_other_thing
foo
rescue BadThing
warn_bad_thing
end
versus
begin
if do_thing
if do_other_thing
foo
else
warn_bad_thing
endif
else
warn_bad_thing
endif
end
Sure, there are ways of cleaning up this construction, but the principle
remains. Don’t encourage bad habits by ignoring them or even supporting
them. Return nil and you can help people do the right thing.
Cheers,
Mike
···
On Sat, 8 Feb 2003, Austin Ziegler wrote:
[Please note that I am way behind on my ruby-talk reading. If you need a quick response, email me directly.]
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
···
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”.