TIL - Rails vs Django Naming Conventions
2025-10-26 blogpage sketch django rails
Rails 8
Created with
rails new my_app → root folder my_app/
Primary directories
app/, config/, db/, bin/, lib/, script/, storage/, test/, vendor/
Rails 8 re-introduced script/ for general-purpose tasks and build scripts.
Inside app/
models/ – singular class names (user_account.rb)
controllers/ – plural class names (users_controller.rb)
views/ – folders named by resource (app/views/users/index.html.erb)
jobs/, mailers/, helpers/, services/, channels/, components/ (for ViewComponent)
Filenames
snake_case with .rb
user_account.rb, users_controller.rb, application_job.rb
Class naming
CamelCase (aka PascalCase)
class UserAccount, class UsersController
Pluralization rules
Model → singular
Database table → plural (UserAccount → user_accounts)
Controller → plural (UsersController)
View folder → plural (users/)
Routing reflection
Controller name and view folder determine URL patterns automatically:
UsersController#index → /users
Configuration files
config/routes.rb, config/database.yml, config/environments/production.rb
YAML and snake_case used throughout.
Assets and frontend
app/assets/ → stylesheets/, javascripts/, images/
app/javascript/ for ESBuild or Importmap setups introduced since Rails 7 and 8.
Testing and specs
test/ (default Rails Minitest) or spec/ (RSpec).
Files mirror app/ structure → test/models/user_account_test.rb
Summary of Rails philosophy
Convention over configuration.
Names express intent, singular/plural carries semantic meaning.
Folder structure is predictable; reflection and autoloading depend on it.
Django (2025)
Created with
django-admin startproject myproject → root folder myproject/
Top level
manage.py → command entrypoint
myproject/ → project package (settings, urls, asgi.py / wsgi.py)
Multiple apps as subdirectories → each represents a domain module.
App creation
python manage.py startapp blog_posts → creates blog_posts/
Inside each app
models.py – ORM models
views.py – views and controllers
urls.py – routing for that app
tests.py – unittests
admin.py – admin integration
apps.py – AppConfig metadata
Sub-folders
migrations/ – auto-created migration files (0001_initial.py)
templates/blog_posts/… – HTML templates
static/blog_posts/… – CSS, JS, images
Optional: forms.py, serializers.py, permissions.py for DRF projects
Filenames
Always lowercase with underscores.
blog_posts/models.py, user_profiles/views.py
Class naming
PascalCase for classes: class UserAccount(models.Model)
snake_case for functions and variables.
Project configuration
settings.py, urls.py, asgi.py, wsgi.py
Each module inside project root uses snake_case names.
Templates and static files
Organized per app to avoid collisions; namespaced by folder.
Global templates/ and static/ supported for shared assets.
Testing and management
tests/ folder in each app or tests.py file.
manage.py acts as universal CLI entrypoint.
Summary of Django philosophy
Explicit over implicit.
Apps are modular and reusable.
Naming favors clarity and flat hierarchy within each app.
Structure is suggested, not enforced.
Comparison
Rails 8 → fixed top-level layout, naming drives autoloading and routing.
Django → flexible per-app layout, naming drives import paths and template resolution.
Rails folders mirror MVC roles directly.
Django folders mirror app modularity and decouple project from apps.
Rails favors pluralization patterns (model ↔ controller ↔ view).
Django favors file-by-responsibility patterns (models.py, views.py, urls.py).
Rails autoload via Zeitwerk depends on directory and class name alignment.
Django uses Python import system – you can rename files freely if imports match.
Rails file names express class identity.
Django file names express module responsibility.
Rails → convention, uniformity, reflection.
Django → explicitness, modularity, freedom.
