image by Stefano Pollio

Use the presence method

Active Support takes a lot flak because it adds methods to core Ruby libraries, most notably patching a lot of functionality into Ruby’s Object class.

RailsConf 2024

I'm co-chairing RailsConf 2024 in Detroit May 7–9. Come and join us 

Every object in Ruby is a subclass of Object, thus if you add methods to it, you’re adding them to every object in your code.

Have a look at the documentation for the enhancements in Active Support to find out more.

One of these methods is #presence, which I don’t see used as much as the more familiar #blank? and #present?.

Instead of…

…using long-winded conditionals to display the value of a variable.

class User < ApplicationRecord
  validates :email, presence: true

  def friendly_name
    if nickname.present?
    elsif given_name.present?


…the #presence method from Active Support.

class User < ApplicationRecord
  validates :email, presence: true

  def friendly_name
    nickname.presence || given_name.presence || email_local_part


  def email_local_part

But why?

Use of the #presence method provides a very convenient shortcut to return either the object (if it exists) or nil.

It is the equivalent of writing object.present? ? object : nil, which is a pattern you often see in views in Rails where data may or may not exist.

It’s also a nice solution when you have an empty string or array. In those cases #presence returns nil.

Why not?

This #presence method is only available in Rails. If you’re only using Ruby it’s probably not worth including Active Support just for this.

Even when using Rails there can be understandable resistance to Rails’ habit of extending standard Ruby classes.

Altering standard classes in your own code, by monkey patching, often causes bugs when the standard Ruby classes begin to behave in unexpected ways. This is the main source of the concern about this style of coding.

Your level of concern about the pitfalls of monkey patching might be strong enough to avoid it even when Rails does it.

Given Rails is a diligently maintained and widely used set of libraries, I consider all and any of it to be safe to use if it makes the resulting code clearer.

Brighton Ruby 2024

Still running UK’s friendliest, Ruby event on Friday 28th June. Ice cream + Ruby 

Last updated on August 19th, 2018 by @andycroll

An email newsletter, with one Ruby/Rails technique delivered with a ‘why?’ and a ‘how?’ every two weeks. It’s deliberately brief, focussed & opinionated.