Rails and Active Record are amazing Ruby gems. They make it so much easier for programmers to build applications with Ruby. But they are very picky about how we name certain things. Pluralization, capitalization, and casing (snake_case vs. TitleCase) all matter when setting up a Rails application. And a single misplaced “s” can take us from this:
But this frustration is easily avoided by naming things properly.
Why is naming so important?
What makes Active Record and Rails so great is that they handle a multitude of tasks for us behind the scenes without us even realizing it. One such function is making associations between different parts of our application. Models are connected to database tables, models are connected to each other, controllers are connected to view files … you get the point. But these associations can only be made with the proper naming conventions (unless we want to do more work and have a bad time). If we don’t follow these conventions, we will most likely get errors that are confusing and hard to debug. Nobody wants that. So let’s avoid it.
OK, how do we do it?
Let’s say we want to set up a new Rails application that keeps track of students and school classes. Students can be enrolled in many school classes, and our school classes can have many students enrolled in them. We have a many-to-many relationship, so we will have three models: students, school classes, and a joiner model which we will call enrollment. Let’s set up our application from scratch.
Step 1: Create the application
The name of the application is not overly important, but it should be relevant to the app. I am going to call ours “students-and-classes-app”. So in our terminal, let’s navigate into the desired directory and write:
rails new students-and-classes-app
Perfect, we have our app. Let’s review the many items we need to set up now within our app. Sticking with MVC convention, we will need the following for each model (student, school class, and enrollment):
- Database Tables
Important Note: As we begin creating and naming things, we MUST stick with the same root word for each of our models. For example, for our school classes model, we are going to name our database table “school_classes.” So anywhere that naming comes up in our app after this, we must stick with some version of “school classes” (school_classes, SchoolClass, etc.) and never switch to just “classes” or “courses” or “chickens” or anything else.
Step 2: Create the database tables
There is no right order in which to create everything, but I like to start with my database tables. To do this, we first create migrations. Here are the naming conventions to keep in mind:
Naming Conventions for Database Tables
Database Table Name: plural, lower-case, snake_case
Database Column Names: singular, lower-case, snake_case
With these in mind, we create our migrations from the terminal:
rails g migration create_students name:string class_year:integerrails g migration create_school_classes name:stringrails g migration create_enrollments student_id:integer school_class_id:integer
Notice that all three of our models have plural database table names. But wait — is “enrollments” the plural of enrollment? Maybe it’s just me, but it sounds weird. Let’s double-check.
If we are ever unsure about the pluralization (or singularization) of a word in Rails, we can check it in a console session. Open up a console session in the terminal with:
To confirm the proper pluralization (or at least the pluralization used by Rails) type:
You should get back the Rails pluralization of “enrollments.” (This is part of how Rails makes associations under the hood). With our suspicions debunked, let’s continue.
We created the migrations, so let’s just double check that everything worked properly. You should now have a “db/migrate” folder in your application with three files in it — one for each migration.
Confirm that these file names are plural. Then before actually migrating them to the database, it is a good idea to open these migration files and double-check that everything looks ok. If everything was done correctly, the migration will look, for example, like this:
After confirming that everything looks good, migrate the tables to the database:
As a last check, open up the newly created “schema.rb” file in your “db” folder and confirm that table names and columns abide by the naming conventions from the beginning of this section. My schema looks like this:
Step 3: Create the models
The next step is creating our Ruby models. There are a lot of places where naming can go wrong here, so let’s follow the following conventions carefully:
Naming Conventions for Models
File Name: singular, lower-case, snake_case, ends with “.rb”
Class Name: singular, upper-case, TitleCase
Belongs To: singular, lower-case, snake_case
Has Many: plural, lower-case, snake_case
We first create model files in the “app/models” folder of our application. In our tree view, our model files will look like this:
Then we define the class for each model within its model file. In our “student.rb” model file, we write:
class Student < ApplicationRecord
has_many :school_classes, through: :enrollments
In our “school_class.rb” file:
class SchoolClass < ApplicationRecord
has_many :students, through: :enrollments
Lastly, in our “enrollment.rb” file:
class Enrollment < ApplicationRecord
Be extra careful with your “has many” and “belongs to” relationships here. Belongs to is singular, has many is plural. It seems obvious but it’s very easy to mix up.
Step 4: Create the controllers
Here are the naming conventions for our controllers. Note that a controller is just a plain old Ruby class:
Naming Conventions for Controllers
File Name: plural, lower-case, snake_case, ends with “_controller.rb”
Class Name: plural, upper-case, TitleCase, ends with “Controller”
Our controller files will go in our “app/controllers” folder. In our tree view, our controller files will look like this:
Then we define each controller within its controller file. In our “students_controller.rb” file, we write:
class StudentsController < ApplicationController
# controller actions go here
In our “school_classes_controller.rb” file:
class SchoolClassesController < ApplicationController
# controller actions go here
Lastly, in our “enrollments_controller.rb” file:
class EnrollmentsController < ApplicationController
# enrollment actions go here
Step 5: Create the views folders
All of our view files (the things that a user will actually see) will need to go in the appropriate view folders, which we must first create and name properly. In our application, we will have a view folder for each of our models. We use the following naming convention for our view folders:
Naming Convention for View Folders
Folder Name: plural, lower-case, snake_case
The view folders will be located in our “app/views” folder and will look like this:
And that’s it! We finally have the basic template set up for our Rails app. Now you can put these mundane set-up tasks behind you and start building out the amazing functionality that’ll make your app one-of-a-kind.