DHH / 37signals Rails Style

Use this guide as a coding-style lens. Give explicit user instructions and repository conventions precedence over its preferences. Preserve established architecture and behavior unless the requested change includes redesigning them.

Infer the relevant area from the task and existing code. Read only the references needed for that area; for reviews, start with the diff. Apply preferences where they clarify the requested change, without introducing a category-selection or approval workflow.

Core style

• Put behavior on the domain object that naturally owns it: card.close, board.publish, subscription.cancel.
• Name operations with domain verbs, predicates with ?, and objects with meaningful nouns. Prefer Card::Closure to a generic CardManager.
• Express state transitions as REST resources when they have a useful identity or lifecycle: create a closure to close a card, destroy it to reopen.
• Keep controllers focused on scoped lookup, permission enforcement, invoking behavior, and the response.
• Group a cohesive model capability in a concern such as Closeable or Watchable. Keep small models direct; extraction needs a clearer concept, not a line-count target.
• Prefer familiar Ruby and Rails primitives before introducing another abstraction. Use plain Ruby domain objects for behavior that does not need persistence.
• Consider a state record when actor, timestamp, history, or lifecycle matters. Keep a boolean for a genuinely binary attribute.
• Make the main path easy to read. Use short methods, intention-revealing locals, and private helpers that name meaningful steps.

References