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.

Example 1

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)

Example 2

You need to hold info on assignments, and each assignment may have multiple tags, a log, and documents. All these data are related to the Assignment, and all should be prefixed with Assignment.

• Bad naming: Assignments, AssignmentDocuments, Log

• Good naming: Assignment, Assignment Document, Assignment Log

In this example, these 3 Object Classes will be adjacent to each other when browsing the list of Object Classes, which makes them easier to find. And we can see that they are related, only by looking at the name.

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.

Example 1

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.

Example 2

Approval properties (2 technical fields)

• Bad naming: ApprovedBy, Date

• Good naming: Approved by, Approved date

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)

Example 1

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

• Bad naming: Add Users

• Good naming: Users

Example 2

In a case-handling system, you have a view for listing and searching all cases, and a dedicated view with process support for handling your cases.

• Bad naming: All cases, My cases

• Good naming: Cases, Case Handling

Example 3

You have a dialog for adding or editing new or existing Users.

• Bad naming: User

• Good naming: New/Edit User

In this example, User is a bad naming because it implies a read only view of a single user. If you have a dialog for a read only view of a Company (e.g. a Company Card), you may name this dialog Company or Company Card.

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.

Example 1

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.

Example 2

We have a Runtime Only Data Source for creating new Persons. This is a Single Cardinality Data Source

• Bad naming: Person

• Good naming: Person (temp), Person (new/edit), Person (runtime)

In this example you see a principle we use a lot: Runtime Only Data Sources are always postfixed with a parenthesis with temp or runtime etc. When viewing e.g. a Data Binding in a User Interface, we can immediately see that a UI Component is bound to a Runtime Only Data Source. Even though the Runtime Only Data Source in most cases are grouped together when browsing the Data Sources list, a good naming will make Actions and User Interfaces more readable.

Actions

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.

Example 1

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

Example 2

We have 4 actions related to manipulation of an Assignment

• Bad naming: Create Assignment, Save Assignment, Add document to assignment, Complete

• Good naming: Assignment - Create and Open Dialog, Assignment - Save and Close, Assignment - Add document, Assignment - Complete.

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.