I have used a little method called returning more and more lately. The implementation of it is built into rails, but the code is incredibly simple:

1
2
3
4
5
6
class Object # all classes inherit from object so this available anywhere.
  def returning(value)
    yield(value)
    value
  end
end

Doesn’t look very exciting, does it? Well first lets look at some code that doesn’t use form the latest app I am working on:

1
2
3
4
5
6
7
8
def self.shipping_rates(zip, weight)
  rates = UPS::Rates.call(zip, weight)
  rates.each do |rate|
    rate.price += Settings.handling_base_price
    rate.price += Settings.handling_bottle_price * qty
  end
  rates
end

So here we get the result of an API call, and we store it in a local variable. The we process it by inflating the prices a bit. Lastly we have to return the rates object since, in this case, the each method returns an array, not my my enumerable object.

I seem to see this pattern a lot. Create an object, iterate through/modify it, return the original object with modifications. The problem is that your modification methods do not return the value you want the whole method to return so you have to manually give it a value to return as the last line. It works but it just feels ugly to me. Adding that last line that does not do anything but only serves to return the proper value just feels messy.

What if we could make this clearer and prettier:

1
2
3
4
5
6
7
8
def self.shipping_rates(zip, weight)
  returning UPS::Rates.call(zip, weight) do |rates|
    rates.each do |rate|
      rate.price += Settings.handling_base_price
      rate.price += Settings.handling_bottle_price * qty
    end
  end
end

The method is still 6 lines, but it’s far cleaner. The returning method does two things:

  1. It returns that object you pass to it as an argument.
  2. It yields the object you pass to it in the attached block.

That’s it. So you can encapsulate this pattern in a simple way. It allows you to modify an object however you want in a block without having to worry about the return value. How many bugs have been tracked down to a model method that does the right thing, but returns the wrong thing. This makes it easier. And, at least in my opinion, much clearer and readable as well.

2 Responses to “"returning" method and prettier code”

  1. James Moore Says:

    I’ve seen a couple other people use this, and I don’t get it. To me, you’re just adding an unnecessary method call and adding to the indent level.

    The unnecessary method means that the person reading the code has to understand what the new ‘returning’ thing does, and what it replaces is perfectly good clean code. And in the original, the last line is crystal clear – it’s the return value. In the new code, the last line is the end of a block, and you have to walk up the lines of code to figure out the likely result of the block.

    The whitespacing, IMHO, makes this uglier. Granted this is subjective, but I think adding another level of indentation subtracts from the beauty of the code. Indentation is problematic because it means you have to look up the page to know what your context is.

  2. Alex Wayne Says:

    The thing is that putting a variable at the end of a method merely to return it’s value just bothers me. And most often that variable has to be initialized near the top of the method. To me, it’s cleaner and clearer to use returning in these cases.

    Ruby’s way of returning the value of the last expression usually works flawlessly, but sometimes the last expression doesn’t return what you want the method to return.

    In those cases it feels cleaner to use returning. But, to each their own. Do what pleases you.

Leave a Reply