Naming Conventions for Concerns in Ruby on Rails

Naming things is hard.

It's the most popular joke in software engineering for a reason.

The two most difficult aspects of software development are caching, naming, and off-by-one errors.

As with most of the Ruby on Rails framework, you get the configuration of Rails with the flexibility of Ruby. So you can really name concerns however you want.

Let's talk about how to name your Rails concerns better.

AWS Made Easy
AWS Made Easy
How to learn AWS quickly and easily.
AWS Made Easy
LEARN MORE

How to Name Concerns

There are a few common patterns you will find across most Ruby codebases, but one stands out as the clear majority favorite.

THE -ABLE NAMING CONVENTION

In short, describe the functionality a concern adds to other classes and append it with "-able".

If you have a concern that gives other classes access to avatars or profile pictures, you might name the concern Avatarable.

It's best to name concerns based on the functionality they add to a class because this provides more context and makes the class overall easier to understand.

And if you're still not convinced, Rails source code even follows this pattern. It has a concern named Configurable that gives a given class some configuration logic.

DRAWBACKS WITH CONCERNS

One of the main drawbacks when it comes to using concerns is the fact that they provide access to methods and associations that aren't defined in the original models.

This can often be confusing or even frustrating.

Having clearly named concerns can help alleviate these drawbacks and give other developers a better idea of where these surprise methods are coming from.

Anyway, here are some more examples.

EXAMPLES OF -ABLE CONCERNS

You might have a few different models in your software that are each written by authors and as a result, need a lot of shared methods to manage authors.

Your blog posts have authors, your comments have authors, and even your testimonials have authors.

Instead of copy/pasting the belongs_to :author association and any methods that are needed in all of these classes, you can extend a concern that makes that class "authorable".

And so you would create an Authorable concern that could look something like this:

module Authorable
  extend ActiveSupport::Concern
  belongs_to :author

  def author_name
    author.full_name
  end
end

Now regardless of if you are dealing with a BlogPost, Comment, or Testimonial model (assuming these are models that would use this concern) you can access any of the code within your concern.

Here's what that might look like:

post = BlogPost.find(42)
post.author_name
=> "Best Author"

comment = Comment.find(21)
comment.author_name
=> "Best Visitor"

testimonial = Testimonial.find(42)
testimonial.author_name
=> "Best Customer"

How to Use a Concern

Concerns are a type of "mixin" and are included in a model by calling include, such as include Authorable.

In the previous example models we used, it could resemble this:

class BlogPost < ApplicationRecord
  include Authorable
end

class Comment < ApplicationRecord
  include Authorable
end

class Testimonial < ApplicationRecord
  include Authorable
end

And now any of these classes would be able to use the shared logic present in the concern.

Granted, just because each of these models is now "authorable", they would still need database migrations such that they could store the author id they are associated to. Don't forget that important step!

But otherwise, as you can see there's no need to be concerned - concerns are pretty straightforward!

Featured
Level up faster
Hey, I'm Nick Dill.

I help people become better software developers with daily tips, tricks, and advice.
Related Articles
More like this
How to Export to CSV with Ruby on Rails
Adding Active Storage to your Rails Project
What is MVC and Why Should I Use It?