Convention over Configuration
Rails' core philosophy — convention trumps configuration
Convention over Configuration (CoC) is Rails' most important philosophy. Instead of configuring everything manually, follow Rails' conventions and everything connects automatically.
Key Conventions:
Model name
Post→ table nameposts(plural, snake_case)Controller
PostsController→ fileapp/controllers/posts_controller.rbView
PostsController#show→app/views/posts/show.html.erbForeign key
user_id→belongs_to :userPrimary key is always
id, auto-generated fields arecreated_at,updated_at
In frameworks like Java/Spring, you need to map everything with XML or annotations, but in Rails, just follow naming conventions. This allows you to focus on feature development immediately without spending time on configuration.
However, without knowing the conventions it can feel like "magic" and debugging becomes difficult, so understanding the conventions precisely is important.
Key Points
rails generate model Post title:string content:text → Post model + posts migration auto-generated
rails generate controller Posts index show → PostsController + view files auto-generated
resources :posts — one line generates 7 RESTful routes
Post.find(1) → SELECT * FROM posts WHERE id = 1 auto-conversion (table name convention)
Omitting render auto-renders view matching action name (show → show.html.erb)
Explicit config only when deviating from conventions (self.table_name = "my_posts")
Pros
- ✓ Saves significant initial setup time
- ✓ Automatic code consistency
- ✓ File location reveals its role
- ✓ Entire ecosystem uses the same conventions
Cons
- ✗ Feels like "magic" without knowing conventions
- ✗ Deviating from conventions can increase complexity
- ✗ Initially confusing for devs from other frameworks
- ✗ Implicit behavior can make debugging harder