rails-conventions

Rails Conventions (Rootstrap)

Apply these whenever producing or modifying Rails-specific code. Full guide: https://github.com/rootstrap/tech-guides/blob/master/ruby/rails.md

Complements ruby-conventions (language-level style still applies).

Configuration

• Custom initialization in config/initializers; one file per gem, named after the gem (e.g. carrierwave.rb).
• Environment-specific settings in config/environments/; shared settings in config/application.rb.
• Create a staging environment that mirrors production.
• Extra YAML config under config/, loaded via Rails::Application.config_for(:yaml_file).
• Append non-default assets to config.assets.precompile in production.rb (e.g. admin CSS/JS). application.* and non-JS/CSS assets are already included.

Routing

• Prefer resources over custom routes; use :only/:except to limit routes.

  # bad
  get 'topics/:id', to: 'topics#show'
  # good
  resources :topics, only: :show
  

• member/collection for extra RESTful actions; use block form when many.
• Express associations with nested routes; use shallow: true beyond 1 level deep.
• namespace to group related actions (e.g. admin).
• Never use the wildcard match ':controller(/:action(/:id(.:format)))' route.
• Avoid match unless mapping multiple HTTP verbs via :via.

Controllers

• Keep controllers skinny — no business logic (belongs in models/services).
• Each action should ideally call only one method beyond an initial find/new.
• Share at most two instance variables between controller and view.

Rendering

• Prefer templates/partials over render inline:.
• render plain: over render text:.
• Use HTTP status symbols, not numbers.

  # bad
  render status: 500
  # good
  render status: :forbidden
  

Models

• Introduce non-ActiveRecord model classes freely; short, meaningful names.
• Use ActiveAttr gem for non-persisted models needing AR-like behavior.
• Keep models for business logic/persistence; move formatting/HTML concerns to decorators.