Actions

Naming conventions

From LimeSurvey Manual

Revision as of 23:18, 18 January 2013 by Sammousa (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.

In short:

- 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.