On , by

At Skcript, we make our code, as structured and beautiful as possible. Some serious work goes into making it.

I HATE when my code looks like a monstrosity of conditions.

If this, do that; 
else if this + 5, do this; 
else if this - 5, do this*5; 
else don't do anything.

There’s way too much logic involved and no effort to simplify it. It’s harder for someone else to understand this, let alone when you yourself look back at this later on. There’s got to be a quantified way to solve this code spaghetti!

There’s a great talk by Sandi Metz at Rails Conf 2014, All the Little Things, that addresses this.

All The Little Things by Sandi Metz, Rails Conf 2014

Her approach is very simple — take your huge monolithic logic, and break it down to smaller, manageable, and reusable components. The rest will sort out over time.

Here are a few of my tricks when reducing complexity,

Return From The Top#return-from-the-top

If you have an ultra simple function that compares a condition to return a value if it matches, and another if it doesn’t. Fairly straight forward scenario.

def pretty_time(time)
   if time
     time.strftime("%B %e, %Y")

Sure it’s not too bad, but it can look even better if you do this,

def pretty_time(time)
 return nil.to_s unless time
 time.strftime("%B %e, %Y")

You can bid good bye to your hanging else statements!

Pipes Are Awesome#pipes-are-awesome

The pipe symbol,|| is a favorite for Ruby devs. You can quickly assign default values when a variable is nil.

> nil || 6
=> 6

But it’s not too friendly with strings.

> "" || "six"
=> ""

When you use this with the presence method, magic happens!

> "".presence || "six"
=> "six"

Try, Try again#try-try-again

If I got a dollar for every time i ran into the nil:NilClass error, I’d be a millionaire! This made me paranoid to stick a if obj.present?everywhere.

if user.present?
  return user.name

*Yuck! *There’s a better way to do this, you just got to keep trying.


Simple! Now when your user doesn’t exists, it will fail quietly and return a nil.

This works with methods too (thanks to Steve Robinson for pointing this out).

If you have a method called fullname, try this out,


Send Off#send-off

I have this horrible habit of organising background workers as if they were logical classes. What I mean is, if I have a few tasks that need to be processed for the user in the background, I put them all in one worker (if it’s not too big). It’s easier to manage, and I don’t have a mess of workers when others collaborate.

Since I have different tasks to be processed for each call of the worker, I pass an “identifier”. Something that tells the worker class what function to perform.

class UserWorker
  include Sidekiq::Worker

  def perform(action, options={})
    if action == :welcome
    elsif action == :process
    elsif ....
    elsif ....


Fortunately, there’s a cleaner way of doing this. This is where Ruby’s powerful meta-programming comes handy. Use send().

What is send?

send( ) is an instance method of the Object class. The first argument to send( ) is the message that you're sending to the object - that is, the name of a method. You can use a string or a symbol, but symbols are preferred. Any remaining arguments are simply passed on to the method.

So from the above mess, this is how my reduced worker looks like.

class UserWorker
  include Sidekiq::Worker

  def perform(action, options={})
    send(action, options)

  def welcome(options)

  def process(options)

So much cleaner, and so much easier to extend.


This particular tip needs to be taken with a pinch of salt. It’s not for everyone, and it might seriously damage your logic if not used carefully.

The great things about Ruby being OOPs complaint is it’s ease of extending base classes like String, TrueClass, and Integer. When used carefully you can do wonders.

I hate doing an if condition for booleans, it just feels wrong. Something like this,

"You are an admin" if user.admin

I’d have to create a specific function in the User class just to handle something as simple as printing out a message if an attribute is true. Here’s a neat trick,

class TrueClass
  def message(m)
    return m

This overrides the TrueClass so you can do something as simple as this,

user.admin.message("You are an admin")

So simple! Now remember to over ride the FalseClass too, so that you don’t run into any method missing errors.

class FalseClass
  def message(m)

There’s so many tiny adjustments you can make with this little trick! Comment down below if you have any improvements of your own.

Share this article on Twitter or LinkedIn
Previous Blog Post: Understanding Flexbox in CSS
Subscribe to Sudo vs Root

Our newsletter rolls out every month. No fluff. Pure content.

Comments and Discussions
Skcript https://www.skcript.com/svr/if-elseif-else-ception/ https://www.skcript.com/svrmedia/heroes/if-else.jpeg

Connect with Skcript Global

In 72-hours, your business gets a clear blueprint of what we can do for your organization.

Contact us

Follow us on Twitter / LinkedIn / Instagram