Is it always the norm to skip 'return'?

[Tito Ciuro]

Hello,

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?

Thanks,

-- Tito

 

[Jeremy McAnally]

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

Hello,

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?

Thanks,

-- Tito

--
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

 

[Peter Hickman]

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

 

[Sebastian Hungerecker]

I think my confusion has to do with not knowing for sure whether a
particular method returns something or not.

In ruby *all* methods return something.

 

[Sebastian Hungerecker]

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?

 

[Sebastian Hungerecker]

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).

 

[Andreas S.]

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.

 

[Greg Donald]

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

 

[Greg Donald]

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.

 

[bbiker]

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.

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

 

[Andreas S.]

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

You could also just write y without the return.

 

[Pat Maddox]

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).

which is just ridiculous.

Pat

 

[Ben Giddings]

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.

Ben

 

[Alex Young]

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.

http://www.research.att.com/~bs/JSF-AV-rules.pdf, section 4.13.2, Return
Types and Values:

"AV Rule 113 (MISRA Rule 82, Revised)
Functions will have a single exit point.
Rationale: Numerous exit points tend to produce functions that are both
difficult to understand and analyze.
Exception: A single exit is not required if such a structure would
obscure or otherwise significantly complicate (such as the introduction
of additional variables) a function’s control logic. Note that the usual
resource clean-up must be managed at all exit points."

This is from a (heavily referenced) C++ style guide, specifically for
code written for the Joint Strike Fighter. I'm no C++ expert, but I'm
led to believe that having more than one exit point in a function in C++
can lead to resource release problems. As such, it would have a clear,
practical effect there. Also, C++ functions tend to be longer (in pure
LOCs) than Ruby methods, so structural complexity is more of a barrier
to comprehension. If you google for "single-entry, single-exit" you'll
find more references to this style and where it comes from - typically
high-reliability embedded system design, as far as I can tell.

It's less of a problem in Ruby, I think, mainly because of the
expressiveness and the presence of GC.