Lately, I’m doing a weird thing when writing Ruby code. I’m trying to only put one idea or action per line. I’m not sure about it yet.

Here’s what a method to fetch item-y things might look like:

def fetch_items(options={})
  limit = options.fetch(:limit)
  timestamp = options.fetch(:timestamp)
  paged_helper = PagedHelper
  client = OurHttpClient

  responses = paged_helper.
    new(limit, timestamp).
    fetch_pages { |params| client.get(params) }

  responses.
    map { |r| JSON.parse(r) }.
    map { |h| ItemCollection.new(h) }.
    map { |ic| ic.items }.
    flatten
end

For the sake of comparison, here’s how I may have written that method a couple years ago:

def fetch_items(options={})
  helper = PagedHelper.new(limit, timestamp)
  responses = helper.fetch_pages { |params| OurHttpClient.get(params) }
  
  responses.map { |r| ItemCollection.new(JSON.parse(r)).items }.flatten
end

I like that the pace of reading the first example is even. You don’t arrive upon some monster line of code that does a multiple things. You don’t have to unpack what’s happening in a situation where you’re calling f(g(h(some_args))). It makes moving lines of code around much simpler because each one is only dependent on what comes before, and not what happens inside. It’s a little easier to write a three-part method, which I really like.

But still, I hesitate. My methods end up about 50% longer. Breaking up the Enumerable transformations into multiple loops instead of one loop doing a bunch of work is probably pretty slow. I have to come up with a lot of names (which is, I think a net good), some of which end up a little redundant.

I’ll let you know how it goes. It may not even survive code review, who knows!

I find methods/functions decomposed into three parts really satisfying. Consider a typical xUnit test:

def test_grants_new_role
  # setup
  user = make_user
  new_role = make_new_role
  
  # behavior under test
  user.add_role(new_role)
  
  # assert results
  assert_equal [new_role], user.roles
end

Lately I’ve been structuring Rails controller similarly:

def create
  # Extract inputs/parameters from HTTP request
  person_params = params.require(:person).permit(:name, :age)

  # Invoke behavior encapsulated in a Plain(ish) Ruby object somewhere
  user = UserService.create_user(person_params)
  
  # Check the result and make some HTTP output
  if user.persisted?
    redirect_to user_path(user.id)
  else
    @user = user
    render :new
  end
end

Clojure even has the let form which encourages this style:

; annotated from clj-http
; https://github.com/dakrone/clj-http/blob/master/src/clj_http/util.clj
(defn gzip
  "Returns a gzip'd version of the given byte array."
  [b]
  (when b
    ; set the table
    (let [baos (ByteArrayOutputStream.)
          gos  (GZIPOutputStream. baos)]
     
      ; do the work and clean up
      (IOUtils/copy (ByteArrayInputStream. b) gos)
      (.close gos)

      ; produce a result
      (.toByteArray baos))))

I don’t think there’s anything inherently wrong if a method or function isn’t organized this way. But when I read code structured this way, it feels less like a bunch of random logic and more like a cohesive unit that someone put time into thinking through how someone might try to understand it later. The Rule of Three rules everything around us.