Is it good style to explicitly return in Ruby?

Coming from a Python background, where there is always a "right way to do it" (a "Pythonic" way) when it comes to style, I'm wondering if the same exists for Ruby. I've been using my own style guidelines but I'm thinking about releasing my source code, and I'd like it to adhere to any unwritten rules that might exist.

Is it "The Ruby Way" to explicitly type out return in methods? I've seen it done with and without, but is there a right way to do it? Is there maybe a right time to do it? For example:

def some_func(arg1, arg2, etc)
  # Do some stuff...
  return value # <-- Is the 'return' needed here?
end

Old (and "answered") question, but I'll toss in my two cents as an answer.

TL;DR - You don't have to, but it can make your code a lot more clear in some cases.

Though not using an explicit return may be "the Ruby way", it's confusing to programmers working with unfamiliar code, or unfamiliar with this feature of Ruby.

It's a somewhat contrived example, but imagine having a little function like this, which adds one to the number passed, and assigns it to an instance variable.

def plus_one_to_y(x)
    @y = x + 1
end

Was this meant to be a function that returned a value, or not? It's really hard to say what the developer meant, as it both assigns the instance variable, AND returns the value assigned as well.

Suppose much later, another programmer (perhaps not that familiar with how Ruby does returns based on last line of code executed) comes along and wants to put in some print statements for logging, and the function becomes this...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
end

Now the function is broken if anything expects a returned value. If nothing expects a returned value, it's fine. Clearly if somewhere further down the code chain, something calling this is expecting a returned value, it's going to fail as it's not getting back what it expects.

The real question now is this: did anything really expect a returned value? Did this break something or not? Will it break something in the future? Who knows! Only a full code review of all calls will let you know.

So for me at least, the best practice approach is to either be very explicit that you are returning something if it matters, or return nothing at all when it doesn't.

So in the case of our little demo function, assuming we wanted it to return a value, it would be written like this...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
    return @y
end

And it would be very clear to any programmer that it does return a value, and much harder for them to break it without realizing it.

Alternatively, one could write it like this and leave out the return statement...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
    @y
end

But why bother leaving out the word return? Why not just put it in there and make it 100% clear what's happening? It will literally have no impact on your code's ability to perform.

No. Good Ruby style would generally only use an explicit returns for an early return. Ruby is big on code minimalism/implicit magic.

That said, if an explicit return would make things clearer, or easier to read, it won't harm anything.

I personally use the return keyword to distinguish between what I call functional methods, i.e. methods that are executed primarily for their return value, and procedural methods that are executed primarily for their side-effects. So, methods in which the return value is important, get an extra return keyword to draw attention to the return value.

I use the same distinction when calling methods: functional methods get parentheses, procedural methods don't.

And last but not least, I also use that distinction with blocks: functional blocks get curly braces, procedural blocks (i.e. blocks that "do" something) get do/end.

However, I try not to be religious about it: with blocks, curly braces and do/end have different precedence, and rather than adding explicit parentheses to disambiguate an expression, I just switch to the other style. The same goes for method calling: if adding parentheses around the parameter list makes the code more readable, I do it, even if the method in question is procedural in nature.

Actually the important thing is to distinguish between:

1. Functions - methods executed for their return value
2. Procedures - methods executed for their side effects

Ruby does not have a native way of distinguishing these - which leaves you vulnerable to writing a procedure side_effect() and another developer deciding to abuse the implicit return value of your procedure (basically treating it as an impure function).

To resolve this, take a leaf out of Scala and Haskell's book and have your procedures explicitly return nil (aka Unit or () in other languages).

If you follow this, then using explicit return syntax or not just becomes a matter of personal style.

To further distinguish between functions and procedures:

1. Copy Jörg W Mittag's nice idea of writing functional blocks with curly braces, and procedural blocks with do/end
2. When you invoke procedures, use (), whereas when you invoke functions, don't

Note that Jörg W Mittag actually advocated the other way around - avoiding ()s for procedures - but that's not advisable because you want side effecting method invocations to be clearly distinguishable from variables, particularly when arity is 0. See the Scala style guide on method invocation for details.

The style guide states, that you shouldn't be using return on your last statement. You can still use it if it's not the last one. This is one of the conventions which the community follows strictly, and so should you if you plan to collaborate with anyone using Ruby.

---

That being said, the main argument for using explicit returns is that it's confusing for people coming from other languages.

• Firstly, this is not entirely exclusive to Ruby. For example Perl has implicit returns too.
• Secondly, the majority of the people that this applies to are coming from Algol languages. Most of those are way "lower level" than Ruby, hence you have to write more code to get something done.

A common heuristic for method length (excluding getters/setters) in java is one screen. In that case, you might not be seeing the method definition and/or have already forgotten about where you were returning from.

On the other hand, in Ruby it is best to stick to methods less than 10 lines long. Given that, one would wonder why he has to write ~10% more statements, when they are clearly implied.

---

Since Ruby doesn't have void methods and everything is that much more concise, you are just adding overhead for none of the benefits if you go with explicit returns.

I agree with Ben Hughes and disagree with Tim Holt, because the question mentions the definitive way Python does it and asks if Ruby has a similar standard.

It does.

This is such a well-known feature of the language that anyone expected to debug a problem in ruby should reasonably be expected to know about it.

It's a matter of which style you prefer for the most part. You do have to use the keyword return if you want to return from somewhere in the middle of a method.

Like Ben said. The fact that 'the return value of a ruby method is the return value of the last statement in the function body' causes the return keyword to be rarely used in most ruby methods.

def some_func_which_returns_a_list( x, y, z)
  return nil if failed_some_early_check
    

  # function code 
  
  @list     # returns the list
end