rails

Rails

• Use private instead of protected when defining controller methods.
• Name date columns with _on suffixes.
• Name datetime columns with _at suffixes.
• Name time columns (referring to a time of day with no date) with _time suffixes.
• Name initializers for their gem name.
• Order ActiveRecord associations alphabetically by association type, then attribute name. Example.
• Order ActiveRecord validations alphabetically by attribute name.
• Order ActiveRecord associations above ActiveRecord validations.
• Order controller contents: filters, public methods, private methods.
• Order i18n translations alphabetically by key name.
• Order model contents: constants, macros, public methods, private methods.
• Put application-wide partials in the app/views/application directory.
• Use lib for code that is not app-specific and could later be extracted into a gem.
• Use app/jobs for code that doesn't need to return anything and can be run asynchronously.
• Use def self.method, not the scope :method DSL. #643
• Use the default render 'partial' syntax over render partial: 'partial'.
• Use link_to for GET requests, and button_to for other HTTP verbs.
• Use new-style validates :name, presence: true validations, and put all validations for a given column together. Example.
• Avoid bypassing validations with methods like save(validate: false), update_attribute, and toggle.
• Avoid instantiating more than one object in controllers.
• Avoid naming methods after database columns in the same class.
• Don't reference a model class directly from a view.
• Don't return false from ActiveModel callbacks, but instead raise an exception.
• Don't use instance variables in partials. Pass local variables to partials from view templates.
• Don't use SQL or SQL fragments (where('inviter_id IS NOT NULL')) outside of models.
• Generate necessary Spring binstubs for the project, such as rake and rspec, and add them to version control.
• Keep db/schema.rb or db/development_structure.sql under version control.
• Use only one instance variable in each view.
• Use the .ruby-version file convention to specify the Ruby version and patch level for a project.
• Use _url suffixes for named routes in mailer views and redirects. Use _path suffixes for named routes everywhere else.
• Validate the associated belongs_to object (user), not the database column (user_id).
• Use db/seeds.rb for data that is required in all environments.
• Use dev:prime rake task for development environment seed data.
• Prefer cookies.signed over cookies to prevent tampering.
• Prefer Time.current over Time.now
• Prefer Date.current over Date.today
• Prefer Time.zone.parse("2014-07-04 16:05:37") over Time.parse("2014-07-04 16:05:37")
• Use ENV.fetch for environment variables instead of ENV[]so that unset environment variables are detected on deploy.
• Use blocks when declaring date and time attributes in FactoryBot factories.
• Use touch: true when declaring belongs_to relationships.

Translations

• Ensure that the application is setup to support multiple locales.
• Ensure that the application raises an error when a translation is missing for a given locale in development and tests.

Migrations

Sample

• Set an empty string as the default constraint for non-required string and text fields. Example. #159
• Set an explicit on_delete behavior for foreign keys.
• Don't change a migration after it has been merged into main if the desired change can be solved with another migration.
• If there are default values, set them in migrations.
• Use SQL, not ActiveRecord models, in migrations.
• Add foreign key constraints in migrations.

Routes

• Avoid the :except option in routes.
• Avoid member and collection routes.
• Order resourceful routes alphabetically by name.
• Use the :only option to explicitly state exposed routes.
• Prefer resource routing over generating routes individually

Background Jobs

• Define a PRIORITY constant at the top of delayed job classes.
• Define two public methods: self.enqueue and perform.
• Put delayed job classes in app/jobs.

Email

• Use the user's name in the From header and email in the Reply-To when delivering email on behalf of the app's users.

Code Review

Follow the normal Code Review guidelines. When reviewing others' Rails work, look in particular for:

• Review data integrity closely, such as migrations that make irreversible changes to the data, and whether there is a related todo to make a database backup during the staging and production deploys.
• Review SQL queries for potential SQL injection.
• Review whether dependency upgrades include a reason in the commit message, such as a link to the dependency's ChangeLog or NEWS file.
• Review whether new database indexes are necessary if new columns or SQL queries were added.
• Review whether new scheduler (cron) tasks have been added and whether there is a related todo in the project management system to add it during the staging and production deploys.

Asset Management

• Use ActiveStorage to manage file uploads that live on ActiveRecord objects.
• Don't use live storage backends like S3 or Azure in tests.

How to...

• Start a New Rails App
• Deploy a Rails App to Heroku
• Feature-test JavaScript in a Rails App