Skip to main content
Version: 2023

Naming conventions

Clear and consistent naming is of great importance during programming. This is particularly true here because functionality can be created on the basis of nomenclature within the Software Factory. The nomenclature is therefore monitored within the Software Factory.

Every name of, for instance, a table, column or reference is built up from sub-names.

We recommend using English for all nomenclature, but it is not mandatory.

Example

The sales order object is written in the Software Factory as sales_order and consists of the sub-names sales and order.

It is agreed within the model that commission is always used and never fee; fee is therefore a rejected sub-name. The plural orders is also a rejected sub-name, since the singular order always needs to be used.

It is recommended to use only approved sub-names and explicitly approved new sub-names. Non-approved sub-names are then highlighted during the validation. A new sub-name can, for instance, also arise as a result of a typing error. In this case, it can be checked where the sub-name is used under the 'Object names' tab. The names of the objects in which the sub-name is used can then be corrected.

Instructions that must be observed within the Software Factory to come to an accurate data model:

  • Names of tables always have to be defined in the singular.

  • Defining tables in plural and columns in the singular leads to a needlessly larger set of sub-names and translation objects.

  • All id-columns need to be written in small letters.

  • Composite words always need to be written separately with an underscore character between them. Do not use spaces in the names.

  • Only for models developed with Dutch names: do not use an "s" connection but write the words separately with an underscore.

  • Repeat the table name in an ID and description column of a table. Not in the other columns. This is very important because the name of a primary key field is transferred as standard to the foreign key. This avoids a table having several foreign key columns with the name id, which of course is not possible because a column name must be unique within a table.

Sub-names are maintained outside the context of the model to enable different models and/or branches to make use of the same source (for example, because there are several models in the company that have to be developed on the basis of the same nomenclature).