A while back, I was reviewing a pull request for a teammate who was building a set of Data Transfer Objects (DTOs) for a complex reporting API. The file was nearly 400 lines long, but most of it was just "pass-through" methods—simple getters that performed a tiny bit of formatting or called a method on an internal object. It looked like a wall of def and end keywords, which made it surprisingly hard to scan for the actual logic. When I pointed out that we could use endless methods to collapse those three-line definitions into one, the look of relief on their face was genuine. It's a small syntactic sugar, but in a large codebase, it removes a massive amount of visual noise.

Trimming the Noise with Single-Line Definitions

Introduced in Ruby 3.0, "endless methods" allow you to define a method without the end keyword, provided the method body consists of a single expression. Instead of the traditional block structure, you use an equals sign (=) to assign the expression to the method definition. It looks a bit like assigning a value to a variable, but you're actually defining the behavior of a method.

# The traditional way
def square(x)
  x * x
end

# The endless way
def square(x) = x * x

The return value is still the result of the last evaluated expression, just like in a standard method. This is particularly satisfying when you're writing simple wrappers or mathematical transformations where a full block feels like overkill.

Practical Applications for Concise Code

I typically lean toward endless methods when I'm dealing with "pure" functions—methods that take an input, perform one operation, and return a result without changing any state. They are perfect for things like custom predicates or formatting logic. For instance, if you're building a User class and you need a helper to check if a user is an administrator based on a role string, an endless method keeps the class definition lean.

class User
  attr_reader :role

  def initialize(role)
    @role = role
  end

  def admin? = role == 'admin'
  def guest? = role == 'guest'
end

Notice how the class reads more like a specification and less like a series of instructions. You can see at a glance exactly what admin? and guest? do without your eyes jumping back and forth between def and end.

Knowing When to Stick to the Block

Now, don't go overboard. I've seen developers try to cram complex logic into a single line just to use this syntax, and that's where you start hurting your future self. If you need to perform a conditional check with an if/else block, or if you need to initialize a local variable to make the logic clearer, stick to the traditional def...end structure.

The moment you find yourself using the ternary operator (condition ? true : false) inside an endless method and it starts stretching past 80 or 100 characters, it's time to break it back out into a full method. The goal is readability, not brevity for the sake of brevity. Use endless methods to remove the boilerplate, not to hide the logic.

📋 Practical Task

Refactoring the CurrencyConverter

You have been handed a CurrencyConverter class that is far too verbose. Your task is to refactor the existing methods into endless methods to make the class more concise. Ensure that the logic remains exactly the same.

class CurrencyConverter
  # Conversion rates relative to USD
  RATES = {
    eur: 0.92,
    gbp: 0.79,
    jpy: 150.12
  }

  def usd_to_eur(amount)
    amount * RATES[:eur]
  end

  def usd_to_gbp(amount)
    amount * RATES[:gbp]
  end

  def usd_to_jpy(amount)
    amount * RATES[:jpy]
  end

  def supported_currency?(currency)
    RATES.key?(currency.to_sym)
  end
end

# Test your refactored class
converter = CurrencyConverter.new
puts converter.usd_to_eur(100) # Should be 92.0
puts converter.supported_currency?("eur") # Should be true