DEV Community

Andy Leverenz
Andy Leverenz

Posted on • Originally published at web-crunch.com on

Best Practices for Naming Models in Ruby on Rails

In Ruby on Rails, naming models is more than just a convention. It's about clarity, efficiency, and ensuring your app is easy to manage. Here's a guide to help you name your models like the pros.

P.S. I created a handy guide at https://web-crunch.com/naming-models. Bookmark it if you need a refresher every once in a while!

Singular and Capitalized

Model names should be singular and capitalized. Rails uses this convention to look for the corresponding pluralized table name in the database.

# Good
class Product < ApplicationRecord
end

# Avoid
class Products < ApplicationRecord
end
Enter fullscreen mode Exit fullscreen mode

Keep it descriptive and clear

Names should be self-explanatory. Don't forget to avoid abbreviations unless they are well-known.

# Good
class ShoppingCart < ApplicationRecord
end

# Avoid
class SCart < ApplicationRecord
end
Enter fullscreen mode Exit fullscreen mode

Organize with namespaces

For complex apps, namespaces help in organizing models. Use modules to group related models.

# Good
module Inventory
  class Item < ApplicationRecord
  end
end

# Usage
@item = Inventory::Item.new
Enter fullscreen mode Exit fullscreen mode

Intuitive Associations

Keep it intuitive. If a User has many articles, the association should reflect that.

class User < ApplicationRecord
  has_many :articles
end
Enter fullscreen mode Exit fullscreen mode

Acronyms and Initialisms

If you're using acronyms, keep them uppercase.

# Good
class HTTPRequest < ApplicationRecord
end

# Avoid
class HttpRequest < ApplicationRecord
end
Enter fullscreen mode Exit fullscreen mode

Avoid Reserved Words

Some words are reserved in Rails and should be avoided as model names (e.g., Attribute, Error).

Context-Specific Naming

If your app has models that only make sense within a specific context, name them accordingly.

# Good for a school management app
class GradeReport < ApplicationRecord
end

# Good for an e-commerce app
class PaymentGateway < ApplicationRecord
end
Enter fullscreen mode Exit fullscreen mode

Avoid Ambiguity

Names should be unambiguous, even if they end up being longer.

# Good
class SubscriptionPayment < ApplicationRecord
end

# Avoid
class Payment < ApplicationRecord
  # This could be ambiguous in an app dealing with multiple payment types
end
Enter fullscreen mode Exit fullscreen mode

Composite Names

For models representing a combination of entities, use clear composite names.

# Good
class UserSubscriptionHistory < ApplicationRecord
end

# Avoid
class UserHistory < ApplicationRecord
  # This is vague about what history it refers to
end
Enter fullscreen mode Exit fullscreen mode

Polymorphic Associations

In polymorphic associations, choose names that clearly indicate their versatile nature.

class Picture < ApplicationRecord
  belongs_to :imageable, polymorphic: true
end

class Employee < ApplicationRecord
  has_many :pictures, as: :imageable
end

class Product < ApplicationRecord
  has_many :pictures, as: :imageable
end
Enter fullscreen mode Exit fullscreen mode

STI (Single Table Inheritance)

The model name should indicate its role if you use Single Table Inheritance.

# Good
class Vehicle < ApplicationRecord
end

class Car < Vehicle
end

class Motorcycle < Vehicle
end
Enter fullscreen mode Exit fullscreen mode

Conclusion

Remember, well-named models make your code cleaner and more accessible for others (or future you) to understand and maintain. I hope these examples add more depth to your understanding! Look for more articles like this to come. In the meantime, check out some related content:

P.P.S. Reminder! I created a handy guide at https://web-crunch.com/naming-models. Bookmark it if you need a refresher every once in a while!

Top comments (0)