Naming conventions: Difference between revisions
From LimeSurvey Manual
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
Having moved to a (partial) MVC architecture we should adopt some conventions for naming our models and controllers. | 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. | 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. | ||
Line 18: | Line 18: | ||
- 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. | - 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. |
Latest revision as of 23:18, 18 January 2013
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.