From LimeSurvey Manual
Having moved to a (partial) MVC architecture we should adopt some conventions for naming our models and controllers. I realize that functionally naming conventions don't have any benefit, however they do increase maintainability. Currently we don't have naming conventions (or I am unaware of them AND they have not been consistently obeyed in the current code base).
The folks at cakephp (http://book.cakephp.org/2.0/en/getting-started/cakephp-conventions.html#model-and-database-conventions) came up with some nice naming conventions.
I suggest we use these for new concepts we introduce to our architecture.
- Models are singular: Plugin not Plugins.
- Database tables backing the model are plural, lowercase: plugins, not plugin or Plugins.
- Controllers are plural if they are "directly" backed by a model: PluginsController, not PluginController.
- Controllers are singular if they are not backed by a model: AdministrationController (which we shortened to AdminController)
- Controllers backed by a main model handle most stuff related to that model. This modularization makes it easy to find the code we are interested in when bugs need fixing.
Table field names:
- Table field names are all lowercase.
- Each table has a primary key named id Do we want this for join tables??
- Each table has either a name or title field, whichever is more appropriate for the model in question. The name / title field should be used for easy identification of a model isntance.
- Foreign keys are named after their model postfixed with _id; so model PluginSetting belongsTo Plugin results in a plugin_id field in the pluginsettings table.
- Join tables (for many2many relations) are either named after the concept they implement, or by concatening the participating models in alphabetical order separated by underscores. For example: user HABTM groups could be stored either in a table called memberships, which would then introduce a model Membership with relations User hasMany Membership and Group hasMany Membership, or alternatively in a table called groups_users.