Use naming conventions

It is important to follow some naming conventions when working in Create. At some point, you as a developer will no longer be handling and maintaining the application. Good naming conventions will make the transition of knowledge easier. In addition, good naming conventions will increase the development speed, since it will simply be easier to look up actions, user interfaces, and data sources.

This section is a suggestion from us in Appfarm based on our experience, and is not mandatory to follow. Most importantly: Have a naming convention that works for you, and make sure you and your team follow it.

Object Classes

Object Classes are one-to-one with a database table. However, the naming of the object class should reflect the data stored in it, and it should be human-readable and understandable. In other words, use natural language with spacing between words. In addition, even though an Object Class may hold multiple instances, do not name the Object Class in its plural form.

You need an Object Class to hold invoice headers and it's rows. This in fact a hierarchy and the naming of these two objects should alphabetically be adjacent and both object classes should have the main purpose (invoice) as part of their name.

  • Bad naming: Invoice, Rows

  • Good naming: Invoice, Invoice Rows (or Invoice Header, Invoice Rows)

Naming of Object Class Properties

We use the same principle for naming Object Class Properties, as we do for Object Classes. The names should be human readable, i.e. with spacing between words. In addition, if we have technical properties, such as date of approval and who approved, we normally use the same prefix for these properties.

The name of a company.

  • Bad naming: CompanyName

  • Good naming: Company Name or Name

In this example, we normally would just name the property Name, since the property is part of the Company, and we do not need to repeat "Company" in the property name.

User Interfaces

The name of a User Interface should reflect the data or purpose of the User Interface. There are in general two types of User Interfaces: Views and Dialogs. When browsing your User Interfaces, the Views will be sorted first (alphabetically), and then the Dialogs will be listed (also sorted alphabetically)

A View for listing all Users with functionality for adding, removing, or editing users

  • Bad naming: Add Users

  • Good naming: Users

Data Sources

When adding Data Sources to your App, its name will default to the name of the Object Class itself. This is fine if you only have one Data Source for each Object Class. However, in most cases, you will have multiple Data Sources for the same Object Class, at least for the core data for Apps of certain sizes.

You have a data source holding all Orders, and another holding only the selected order

  • Bad naming: Orders, Order

  • Good naming: Orders, Order (selected)

In this example, you see a few general principles we use. We use the multiple form of the Data Source has cardinality Many, and we add a short precision of the Data Source in parenthesis (e.g. Order (selected)), which briefly explains the data filter, since this is important information. The fact that the Orders Data Source many only hold Orders last year does not reflect in its name. However, if we had 2 Data Sources holding many Orders, we would add parenthesis to the Data Source names of these two as well.


We use two principles here. The action names should reflect the purpose / what task the action performs, and similar actions should alphabetically be grouped together.

We have 3 actions for navigating from the menu to 3 different views.

  • Bad naming: Orders, Users, Go to Companies

  • Good naming: Nav - Orders, Nav - Users, Nav - Companies

In the above example, we prefix the navigational actions with "Nav -".

Action Nodes

In general, the names of action nodes are autogenerated (by the type of action node). But in general, we use the names of action nodes as a short description when the default naming is not self-explanatory.

An example of such is the IF-action node. If the IF-condition is a self-explanatory one-liner, we do not name it. But if the condition is complex, we normally add a short name serving as a description of when the condition should trigger.

Last updated