How to Write Better Ruby Methods — The Composed Method Technique

In my search to write better code, I’ve stumbled across a technique to write better methods. It’s called The Composed Method Technique (from Eloquent Ruby).

The composed method technique basically has 3 rules.

• Each method should do a single thing
• Each method needs to operate at a single conceptual level
• Each method needs to have a name that reflects its purpose

Let’s walk through what each of these rules mean.

Each method should do a single thing

Each method should focus on solving a single aspect of the problem. So if your method is solving two problems, then you should be creating a new method. For example, consider the following method that determines if one should transition from one relationship to another (the following displays of code are just fun examples to try to explain the concept, please don’t be mean!):

This is such messy code (and a horrible algorithm to begin with…) The transition method does so many things: it tries to see if there’s still love between the two, it tries to see if the partner is life partner material, it tries to see if a side chick exists and if the partner knows about her, and if so, break up with the partner and seek out other potentials. All in all, this method is a mess. Again,each method should do a single thing.

Let’s seperate each problem into a method and see what it looks like (still a horrible algorithm):

Although I advise absolutely no one to try out this algorithm in real life, the code itself is much easier to read and understand. Splitting the methods into small little chunks result in better code.

Each method needs to operate at a single conceptual level

This basically means not to mix high-level logic with the nitty-gritty details. For example, the transition method holds high-level logic and branches out to other methods:

What we don’t want is something like this:

It’s much better organized if the conceptual level is constant as we saw in the above example.

Each method needs to have a name that reflects its purpose

This one is quite straightforward. In essense, what we don’t want is something like this:

or this:

A method named eat_cheeseburger is expected to eat a cheese burger, not say a cliche break up quote and set current_partner to null. Similarly, a method named draw_circle is expected to draw a circle, not figure out complicated love matters.

In these situations, names like break_up! or love_still_exists? makes 500% more sense.

Writing Shorter Methods

Applying the composed method technique allows you to write shorter and smaller methods instead of long ones. There are several merits to writing shorter methods in Ruby.

The first is that writing smaller details will help you get the details correct. It’s the same idea to writing pseudocode — except you are defining a new method for each line of pseudocode.

The second is that it’s easier to test with smaller methods. If a method contains a solution to more than one problem, you can’t isolate a buggy solution; you can only test the entire method. If you have methods that are divided into seperate purposes, you can isolate them and test if they work. It’s much easier to debug this way.

The last upside is that in Ruby, the composed method way of defining and building classes is super effective since the cost of defining a new method in Ruby is extremely low. You just need an additional def and end. In other languages, it can take a little bit more code and thus a little bit more costly. The cost performance of defining a new method in Ruby is high and there’s really no reason not to define a new method.

Unless you are over doing the “short methods” thing. Your “short method” should actually do something and you shouldn’t just define a short method because you can:

I hope my poorly thought out algorithm was able to explain the topic of writing better methods in Ruby. I apologize for my lack of relationship intelligence, if you have any suggestions please reach out to me as I would like to refactor my poorly constructed model of how one should transition between relationships.

Happy coding!

I write about coding in my personal blog. Every now and then, I share coding articles that I’ve found or written that you might find to be useful or interesting. Subscribe here.

If you found the post useful, please recommend and follow :)