Best Practices for Naming Models in Ruby on Rails
Tags: ruby, rails, tutorial
Published: 2023-12-19 17:34:06

---
title: Best Practices for Naming Models in Ruby on Rails
published: true
date: 2023-12-17 13:33:10 UTC
tags: ruby, rails, tutorial
canonical_url: https://web-crunch.com/posts/best-practices-for-naming-models-in-ruby-on-rails
---

{% youtube I3qyHJUNLn8 %}

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](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.

```ruby
# Good
class Product < ApplicationRecord
end

# Avoid
class Products < ApplicationRecord
end
```

### Keep it descriptive and clear

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

```ruby
# Good
class ShoppingCart < ApplicationRecord
end

# Avoid
class SCart < ApplicationRecord
end
```

### Organize with namespaces

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

```ruby
# Good
module Inventory
  class Item < ApplicationRecord
  end
end

# Usage
@item = Inventory::Item.new
```

### Intuitive Associations

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

```ruby
class User < ApplicationRecord
  has_many :articles
end
```

### Acronyms and Initialisms

If you're using acronyms, keep them uppercase.

```ruby
# Good
class HTTPRequest < ApplicationRecord
end

# Avoid
class HttpRequest < ApplicationRecord
end
```

### 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.

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

# Good for an e-commerce app
class PaymentGateway < ApplicationRecord
end
```

### Avoid Ambiguity

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

```ruby
# Good
class SubscriptionPayment < ApplicationRecord
end

# Avoid
class Payment < ApplicationRecord
  # This could be ambiguous in an app dealing with multiple payment types
end
```

### Composite Names

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

```ruby
# Good
class UserSubscriptionHistory < ApplicationRecord
end

# Avoid
class UserHistory < ApplicationRecord
  # This is vague about what history it refers to
end
```

### Polymorphic Associations

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

```ruby
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
```

### STI (Single Table Inheritance)

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

```ruby
# Good
class Vehicle < ApplicationRecord
end

class Car < Vehicle
end

class Motorcycle < Vehicle
end
```

### 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:

- [A Beginner's Guide to Ruby on Rails Callbacks](https://dev.to/justalever/a-beginners-guide-to-ruby-on-rails-callbacks-4noh)
- [Understanding Active Record Callbacks](https://dev.to/justalever/understanding-active-record-callbacks-2l2g)
- [Understanding Active Record Associations](https://web-crunch.com/posts/understanding-active-record-associations)
- [Understanding Active Record Migrations](https://web-crunch.com/posts/understanding-active-record-migrations)
- [Understanding Ruby on Rails ActiveRecord Validations](https://web-crunch.com/posts/understanding-ruby-on-rails-activerecord-validations)

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