I have a question about skipping the ‘return’ keyword in a Ruby method.
For example:
def self.encrypted_password(password, salt)
string_to_hash = password + salt
Digest::SHA1.hexdigest(string_to_hash)
end
Being used to work in other languages, this is weird to me. Without
looking at the documentation, I have no way of knowing that ‘hexdigest’
returns a string. Wouldn’t the following be easier to understand?:
def self.encrypted_password(password, salt)
string_to_hash = password + salt
return Digest::SHA1.hexdigest(string_to_hash)
end
Why so many Ruby snippets skip the ‘return’ keyword?
Ruby always returns the last value used in the method; it’s pretty
redundant to use return in most cases. In your example, I see no
reason to use return. I see that
Digest::SHA1.hexdigest(string_to_hash) was the last value used in the
method, so therefore I know that’s what is coming back to the code
that called it.
It’s a Ruby idiom, but it’s not as confusing as some.
On Oct 19, 2007, at 8:28 AM, Jeremy McAnally wrote:
Ruby always returns the last value used in the method; it’s pretty
redundant to use return in most cases. In your example, I see no
reason to use return. I see that
Digest::SHA1.hexdigest(string_to_hash) was the last value used in the
method, so therefore I know that’s what is coming back to the code
that called it.
It’s a Ruby idiom, but it’s not as confusing as some.
–Jeremy
I think my confusion has to do with not knowing for sure whether a
particular method returns something or not. Perhaps my example was not
the best one. I’ve seen some ambiguous methods that makes you really
wonder whether it returns something or not. I think that if a
statement was preceded with a return, it would be a little easier to
recognize. Not a biggie
Digest::SHA1.hexdigest(string_to_hash)
end
Because Ruby lets you be lazy like that. You can put it in if you
want but
you don’t have to so laziness prevails.
However how does your adding return address your issue with not
knowing what
the last method call returns?
Well, if I’m looking at some code with a return statement as shown
above, I tells me that Digest::SHA1.hexdigest returns a string, which
in turn the method returns as well. I don’t really need to check the
documentation.
I just think that in this case it pays off to be a little less lazy
For the simpler methods it does seem to be a waste to put a return in
there however it should be remembered that the “if” also returns a
value. So
def other(number)
if number == 1 then
puts “In the true condition”
“the number was 1”
else
puts “In the false condition”
“it was something else”
end
end
puts other(21)
outputs
In the false condition
it was something else
The implicit return here is for the whole of the if. Which can be quite
a pain to track down
anything,
you can’t know it returns a string just by the fact that there’s a
return in
front of it. You can only tell that by looking at it’s documentation.
What does the return keyword have to do with what kind of object a
method
returns?
That’s not what I meant. You’re right, the return keyword has nothing
to do with the return type.
What I meant is that without the return, to me it looks like a one-way
method. If I see a ‘return’, I know there is something being returned.
To me, and possibly other people as well, the inclusion of ‘return’
would make things clearer. That’s all
def self.encrypted_password(password, salt)
string_to_hash = password + salt
return Digest::SHA1.hexdigest(string_to_hash)
end
Well, if I’m looking at some code with a return statement as shown
above, I tells me that Digest::SHA1.hexdigest returns a string
Where does it tell you that? I don’t get it. hexdigest could return
anything,
you can’t know it returns a string just by the fact that there’s a
return in
front of it. You can only tell that by looking at it’s documentation.
What does the return keyword have to do with what kind of object a
method
returns?
What I meant is that without the return, to me it looks like a one-way
method. If I see a ‘return’, I know there is something being returned.
As I said in my other message: every method returns something in ruby
(though not necessarily something useful). There are no void methods
in ruby (I assume, that’s what you mean by one-way).
But I think it’s still a good idea to use return in order to document
that the method is MEANT to return something, and that it’s not just an
unintended side effect.
If you want to use return, use it. The value returned by a Ruby method
is t
What I meant is that without the return, to me it looks like a one-way
method. If I see a ‘return’, I know there is something being returned.
As I said in my other message: every method returns something in ruby
(though not necessarily something useful). There are no void methods
in ruby (I assume, that’s what you mean by one-way).
But I think it’s still a good idea to use return in order to document
that the method is MEANT to return something, and that it’s not just an
unintended side effect.
But I think it’s still a good idea to use return in order to document
that the method is MEANT to return something, and that it’s not just an
unintended side effect.
If you want to use return, use it. The value returned by a Ruby method
is t
What I mean to say is the returned value is always going to be the value
of the last evaluated expression. Not having to use return is good.
It’s smaller code and once you get used to it, it seems very normal.
I have a question about skipping the ‘return’ keyword in a Ruby method.
[snip]
Why so many Ruby snippets skip the ‘return’ keyword?
Thanks,
– Tito
Because it’s not needed and it’s considered bad style to introduce
unnecessary noise in Ruby. Every method call returns a value. In the
absence
of a return statement, it is the value of the last expression in the
definition. So, whether you want it or not, it happens. Better to get
used
to that, take advantage of it and save yourself a few keystrokes than to
think that you typing return at the end of a method definition makes any
difference at all.
The only time to use return is when you return from the middle of a
method,
but even that is considered bad programming practice (functions should
have
only one exit).
Because it’s not needed and it’s considered bad style to introduce
unnecessary noise in Ruby. Every method call returns a value. In the absence
of a return statement, it is the value of the last expression in the
definition. So, whether you want it or not, it happens. Better to get used
to that, take advantage of it and save yourself a few keystrokes than to
think that you typing return at the end of a method definition makes any
difference at all.
The only time to use return is when you return from the middle of a method,
You’re doing great up until
but even that is considered bad programming practice (functions should have
only one exit).
On Sat, 20 Oct 2007 00:38:42 +0900, Peter H. wrote:
end
a pain to track down
I think that’s not true, and you’re mistaking the output of “puts” on
the
function (which IS nil) for the output of the if statement (which is the
output of the branch that’s taken).
I know I’ve seen and used the if/else implicit-return idiom, and a quick
IRB check (1.8.6 Cygwin) shows:
irb(main):001:0> def other(number)
irb(main):002:1> if number == 1
irb(main):003:2> “it was one”
irb(main):004:2> else
irb(main):005:2* “it was not one”
irb(main):006:2> end
irb(main):007:1> end
=> nil
irb(main):008:0> other(21)
=> “it was not one”
irb(main):009:0> puts other(21)
it was not one
=> nil
irb(main):010:0> other(21).inspect
=> ““it was not one””
The only time you need to implicitly use ‘return’ is when you want the
value of a variable that was processed prior to the last statement.
for example:
y = some_method(alpha, beta)
do_some_cleanup before returning
return y
Actually, I’d say the only reason you should use return in a method
is when you want to jump out of a method with a value and stop doing
anything else, i.e.
def foo(arg)
arg.each do |e|
if e.meets_some_condition?
return e.text
end
end
“Not found”
end
The advantage of only using “return” when you want to return
prematurely is that it clues people into the fact that you’re exiting
prematurely. Otherwise you know that the method always returns the
value of the last expression you evaluate.
but even that is considered bad programming practice (functions should have
only one exit).
which is just ridiculous.
I concur. There’s nowhere that says that functions should have just one
exit - it doesn’t necessarily make for bad style, or code noise.
Sometimes the most elegant way is just to drop out, rather than
changing the control structure of your entire method.
