Rails argues for "convention over configuration" to minimize time spent by programmers worrying about menial details and maximize time spent on substantive problem solving.
Model and controller naming conventions
- Model and class names are singular (
Post) and in CamelCase (
AccessControlList); if you use
script/generate modelto create a model the class file will be in lowercase, singular, separated by underscores (
- Database tables corresponding to models/classes are plural (
posts) and in lowercase, separated by underscores (
- Controller names are not required to match up with underlying model names, but when they do the convention (not enforced) is to use the plural form of the model name (
WeblogsController, the corresponding file name would be
weblogs_controller.rb); if you use
script/generate controllerto create a controller file Rails will not perform and singular-to-plural conversion but will format the name in lowercase with underscore separators.
- If you use
script/generate scaffoldto create a scaffold Rails will create a singular model file and a plural controller file.
Database naming conventions
- Table columns of type
updated_onwill be automatically updated by Rails on record creation and record update respectively.
- Table columns named
lock_version(type: integer, default: 0, null: false) will be used automatically by Rails to perform "optimistic locking" (an exception will be raised whenever a race occurs).
- A column named
counter_cachecan be used to save database lookups (see: http://blog.gorgorg.org/articles/2006/04/04/ruby-on-rails-how-to-actually-use_count-counter_cache).
Model inheritance conventions
Given a class hierarchy that looks like this:
Rails will expect a single table named
furniture with a column named
type that will be used to distinguish which rows are used for the
Chair model and which for the
Table model. For more information see:
- If you create a file at
app/views/layouts/application.rhtmlit will automatically be used as a wrapper around all other layouts.